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

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

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

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

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

Мировая практика показывает, что стоимость программного обеспечения и услуг по его настройке для создания финансового приложения конкретного предприятия соотносится как 1:3 — 1:7. Это означает, что на каждый рубль, затраченный на программное обеспечение, приходится от трех до семи рублей услуг специалистов.

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

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

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

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

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

• Настройка системы на бизнес-логику предприятия, настройка справочников, форм документов, формирование аналитического плана счетов.

• Создание блоков проводок, обеспечивающих формирование аналитических данных высокого качества.

• Встраивание учетной системы в информационный контекст предприятия — подсоединение к информационным потокам предприятия.

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

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

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

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

• концепция обмена данными через аналитику проводок;

• концепция снижения вариативности в периферийных слоях информационной системы.

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

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

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

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

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

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

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

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

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

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

• необходимость распознавания состояния на более детальном уровне также приводит к изменению в алгоритмах обработки и структуре данных не только на уровне данного документа, но и на уровне многих связанных с ним;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• проверкой значения определенных полей документа (статусы);

• проверкой сальдо на счете, соответствующем данному решению;

• под управлением внешнего документооборотного механизма.

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

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

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

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

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

Рассмотрим архитектуру построения Алеф.Бухгалтерии в аспекте гибкости и переносимости. На рис. 3 изображены архитектурные слои Алеф.Бухгалтерии.

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

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

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

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

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

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

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

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

На рис. 4 приведена принципиальная схема Алеф.Бухгалтерии, позволяющая еще раз осознать назначение блоков:

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

• блока проведения, состоящего из конструктора проводок;

• блока хранения, представленного аналитическим планом счетов.

Рассмотрим подробнее некоторые элементы блока представления, проведения и хранения аналитических данных.

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

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

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

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

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

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

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

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

• На различных участках учета имеется доступ к различному набору типов документов.

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

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

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

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

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

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

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

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

Конечно, каждый профильный документ может быть связан с несколькими типами документов. Типы документов также могут быть связаны с несколькими профильными. Например, тип документа “Физическое лицо” может быть связан с профильными документами “Физическое лицо”, “Контрагент” и т.д. С другой стороны, Профильный документ “Контрагент” может формироваться типами документов “Физическое лицо”, “Юридическое лицо” и др.

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

Блок проведения состоит из интерпретатора данных, конструктора проводок и генератора проводок. На рис. 6 представлена структурная схема блока проведения.

 Рис. 6. Структурная схема блока проведения

Механизм создания проводок состоит из трех основных узлов:

• интерпретатор данных;

• конструктор проводок;

• генератор проводок.

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

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

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

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

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

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

Конечно, структура аналитического плана счетов различается в каждом конкретном случае.

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

Для каждого параметра указывается набор имен аналитики. После определения номера счета конструктор проводок запрашивает состав аналитических разрезов данного счета плана счетов. Результатом данного запроса будут пары (Позиция — Имя аналитического разреза). Для нашего примера результат будет выглядеть следующим образом:

Код K — Поставщик;

Код L — Период оказания услуг;

Код M — Период оплаты.

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

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

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

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

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

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

• взаимодействие на уровне документов (OLE, DDE,ODBC …);

• взаимодействие на уровне профильных документов (OLE, DDE,ODBC …);

• взаимодействие на уровне программного интерфейса (OLE, DDE,ODBC …);

• взаимодействие на уровне ядра данных (хранимые процедуры SQL сервера, триггера, данные таблиц).

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

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

Для организации совместного выполнения функций очень удобным и мощным инструментом являются алгоритмы документов. В алгоритмах могут быть вызваны функции, созданные на языке PowerScript, который, являясь объектным языком, обладает необходимыми свойствами для обращения к данным по протоколам OLE, DDE, ODBC и т.п. Кроме того, могут быть использованы протоколы высокого уровня (MAPI и другие).

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

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

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

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

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

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

• Документы позволяют гибко сформировать удобный пользовательский интерфейс, обеспечив с помощью алгоритмов контроль бизнес-логики и выполнение определенных функций как в Алеф.Бухгалтерии, так и во внешних приложениях по протоколам высокого уровня (OLE, DDE) или посредством доступа к данным по протоколу ODBC. Из алгоритмов документов также доступны почтовые и иные специфические протоколы для обеспечения взаимодействия.

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

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

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

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

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