Тенденции развития систем комплексной автоматизации учета и управления

Развитие учетных подсистем

Вполне естественно, что задача разработчиков программ состоит в обеспечении соответствия подсистем бухгалтерского учёта требованиям законодательства. Все поставщики бухгалтерского ПО так или иначе заранее подготовились к переходу на новый План счетов и вступлению в силу второй части Налогового кодекса РФ. Следует отметить, что гибкость существующих разработок такова, что с формальной точки зрения переход на новый План счетов не представляет для пользователей особых затруднений, поскольку справочники счетов являются открытыми для внесения изменений, а порядок формирования бухгалтерских записей также может быть необходимым образом модифицирован. Другой вопрос заключается в том, какие готовые настройки тех же типовых операций производитель поставляет своим пользователям. И здесь, конечно, имеются существенные различия.

Фирмы, ориентирующиеся на массовый тираж своих программных продуктов, созданию подобных настроек уделяют очень серьезное внимание, полагая, что многие клиенты используют именно их типовые решения. Те же поставщики, которые сами обеспечивают внедрение своих разработок, типовыми решениями занимаются заметно меньше, поскольку всё равно "подкручивают" настройки своих программ на каждом объекте внедрения. Особенно разительны эти отличия с точки зрения создания типовой методологии учёта, ориентированной на автоматизированное составление форм регламентированной отчётности. Если такие производители программ, как "1С", "ДИЦ", "Информатик", более или менее регулярно поставляют зарегистрированным пользователям готовые настройки для формирования отчётности, то поставщики индивидуальных решений, похоже, вообще не придают этому значения.

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

Функции управления документооборотом

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

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

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

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

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

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

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

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

Гибкость в организации расчётов

Благодаря развитой организации и продуманной поддержке документооборота в названных разработках аналитический учёт может быть необходимым образом распределён по различным подсистемам, аналогично тому, как это реализовано в системе "Галактика", заслужившей положительные отзывы многих экспертов. Разработчики "Инфософта" и "Компаса" в некотором смысле даже пошли дальше: работая с их системами, пользователь может выбирать, распределять ли аналитический учёт по подсистемам управления (что, на наш взгляд, целесообразнее всего), или же вести произвольный объём функций аналитического учёта в бухгалтерии.

Так, например, с помощью модуля "Бухгалтерия" системы "Флагман" ("Инфософт") может быть организован аналитический учёт почти любой сложности: к какому-либо счёту можно привязать до 15 типов аналитических счетов. Поддерживаются как предопределённые, так и произвольные аналитические разрезы. К первым относятся субъекты учёта (контрагенты, сотрудники), объекты учёта (всё, что подлежит не только суммовому, но и количественному учёту), статьи и центры затрат. Вторые (произвольные) разрезы могут быть увязаны с любыми ведущимися в системе списками. Особо следует отметить то, что настройка аналитического учёта в бухгалтерской подсистеме производится предельно просто, чего нельзя сказать о многих других разработках.

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

Говоря о гибкости организации различного рода типовых расчётов, следует отметить ещё и такое важное свойство программы фирмы "Компас", как возможность выбора конкретного механизма списания себестоимости товарно-материальных ценностей. Дело в том, что программы вычисляют средневзвешенные цены, а также оценки методами ФИФО и ЛИФО по-разному. Проиллюстрируем данную проблему на простом примере вычисления средневзвешенных цен. Пусть один и тот же товар поступил на два склада предприятия от разных поставщиков несколькими партиями, что отражено в табл. 1. Для упрощения примера будем считать, что цены приведены в рублях.

Из приведённых в табл. 1 данных следует, что средневзвешенная цена данного вида товара по складу № 1 составляет 110 руб., по складу № 2 - 120 руб., а в целом по предприятию себестоимость составит 115 руб.: (2200 + 2400) / (20 + 20).В условиях нашего примера данные по себестоимости склада и предприятия отличаются не только при использовании методики оценки по средним ценам, но и при применении методов ФИФО и ЛИФО. Поэтому ответ на вопрос, какова себестоимость отгруженного со склада № 1 товара, будет сильно зависеть от того, какая "средняя" применяется в вычислениях: по складу № 1 или в целом по предприятию.

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

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

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

Если, основываясь на данных приведённого примера, списать себестоимость товара по состоянию на 10-е число, то списанная сумма составит 1000 руб., а если за месяц в целом, то 1100 руб. (по средневзвешенной цене за месяц). При использовании метода ФИФО результаты списания будут идентичными (поскольку всегда сначала списываются первые по поступлению партии), а результаты списания по методу ЛИФО - различными.

Традиционно при ручном учёте периодом расчёта является месяц, поэтому средневзвешенные цены или оценки методом ЛИФО выводятся в целом за данный период. Это вполне объяснимо, поскольку вручную производить оперативный пересчёт показателей оценки запасов по большой номенклатуре весьма затруднительно.

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

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

Однако в этом случае складской учёт можно вести только в натуральном выражении.

Предположим, что в условиях первого примера со склада № 1 отгружены обе поступившие на него партии товара. Конечно, следовало бы списать со склада всю их стоимость, т. е. 2200 руб., однако, если программа вычисляет средневзвешенную цену в целом по предприятию, то, скорее всего, в ней реализован алгоритм, в соответствии с которым вычисления будут производиться путём перемножения списываемого количества (20 единиц) на средневзвешенную цену по предприятию (115 руб.). В результате остаток в натуральном выражении на складе № 1 будет равен нулю, а в стоимостном выражении окажется отрицательным (-10 руб.).

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

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

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

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

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

Программы экономического анализа

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

Среди представленных на конкурс программ финансового анализа помимо программы - победителя ("АФСП", разработка фирмы "ИНЭК") хотелось бы выделить ещё две разработки: модуль "Финансовый анализ" корпорации "Галактика" и программу Audit Expert фирмы "Про-Инвест-ИТ". По сравнению с большинством других представленных на российском рынке систем такого рода они позволяют не только решать стандартные задачи финансового анализа, но и имеют серьёзные механизмы, обеспечивающие пользователю возможность создавать собственные методики анализа, в том числе и внутрихозяйственного.

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

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

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

Заслуживают внимания и решения, ориентированные на банковский сектор, представленные фирмами R-Style Software Lab. и InterSoft Lab. Первая система пока ещё находится в стадии разработки и опытной эксплуатации и в большей степени предназначена для крупных банков. Она в полной мере поддерживает все современные концепции создания аналитических систем данного класса, но, как нам показалось, потребует значительных затрат на приобретение лицензий и внедрение.

Другая разработка - система "Контур Стандарт" фирмы InterSoft Lab. - хотя и имеет определённые ограничения, но уже представляет собой готовый тиражный продукт, выступающий и как средство разработки прикладных аналитических бизнес-приложений, и как среда их исполнения. Система относится к виду DOLAP (Desktop On-line Analytical Processing - настольная система анализа данных в режиме реального времени) и предназначена для индивидуальной работы с корпоративными данными. Программа поставляется в двух вариантах. Первый (Developer) позволяет строить аналитические модели и исполнять их. Приложения (в том числе по каждому направлению деятельности) могут создаваться как сотрудниками самого предприятия, так и независимыми разработчиками. Каждое бизнес-приложение представляет собой комплект аналитических отчётов заданной тематики. Второй вариант поставки включает только среду исполнения моделей (Runtime). Он не даёт возможности строить новых моделей, но позволяет работать с уже готовыми моделями приложений. При этом пользователю не надо думать о том, каким образом загрузить исходные данные и как их интерпретировать: все необходимые настройки выполнены при создании приложения.

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

В качестве источников анализируемой информации в системе "Контур Стандарт" могут применяться базы данных любых эксплуатируемых в организации автоматизированных систем, хранящиеся в форматах СУБД различного типа - xBase, Paradox, Access, MS SQL-server, ORACLE и т. п. Доступ к ним осуществляется путём прямого обращения или импорта данных в заведённые пользователем локальные таблицы. Имеется возможность создания собственных источников данных, например загрузки текстовых файлов формата *.csv. Прямой доступ к информации реализуется через библиотеки BDE (Borland Database Engine) и технологию ODBC (Open DataBase Connectivity).

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

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

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

Следует отметить, что идея создания OLAP-систем всё больше привлекает внимание разработчиков. В этой связи хотелось бы привести в качестве примера разработку фирмы "Инталев". Она не была представлена на этом конкурсе, и поэтому автор данной статьи не знаком с её последними версиями, но мы посчитали целесообразным упомянуть её, поскольку она предназначена для многотысячной армии пользователей системы программ "1С:Предприятие".Все перечисленные разработки основаны, условно говоря, на "классических" принципах построения OLAP-систем, хотя и с некоторыми оговорками. Но на конкурсе было продемонстрировано и нетрадиционное решение в этой области. Его представила фирма "Комсофт", которой удалось реализовать значительную часть функционала OLAP-системы за счёт связки планово-учётных подсистем своей основной разработки с возможностями механизма сводных таблиц Excel. Здесь специальный переходной блок готовит данные для передачи их в Excel, а пользователь, применяя средства сводных таблиц Excel, может обращаться с этими данными по своему усмотрению. Возможно, это решение выполнено не столь красиво, как в системе от Cognos, но с точки зрения практических возможностей нужной "раскладки" данных оно даёт почти тот же самый результат. Конечно, рафинированные IT-специалисты могут возразить, что это не совсем "настоящий" OLAP и что Excel "захлебнётся" на большом объёме данных, но ведь для большинства российских предприятий речь пока идёт о скромных возможностях и масштабах. Поэтому применение более простых аналитических OLAP-моделей в качестве подобных решений, на наш взгляд, следует только приветствовать.