АВТОМАТИЗАЦИЯ УЧЕТА
УДК 004.051
КОНЦЕПЦИЯ СТАНДАРТИЗАЦИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ БУХГАЛТЕРСКОГО УЧЕТА
Б. А. КОСТИН,
ведущий специалист Департамента информационных технологий E-mail: borisak@tfb. ru ОАО «АИКБ Татфондбанк»
И. А. КОНОПЛЕВА, кандидат технических наук, доцент кафедры математики и информатики, профессор Е-mail: apollo@atknet. ru Всероссийский заочный финансово-экономический институт, филиал в г. Архангельске
В настоящее время возникла настоятельная необходимость в разработке новых подходов и выработке концепции к стандартизации автоматизированных систем бухгалтерского учета. В статье предложен нетрадиционный подход к разработке типовых решений задач бухгалтерского учета на базе средств вычислительной техники, которые будут удовлетворять требованиям потребителей. Авторами рассмотрены предмет стандартизации, критерии оценки эффективности существующего программного обеспечения, предложена концепция, обеспечивающая возможность качественно и прозрачно реализовать требования к автоматизированной системе бухгалтерского учета разных социальных агентов, а также настраивае-мость системы на любые законодательные и технико-экономические условия.
Ключевые слова: автоматизированная система бухгалтерского учета, Лука Паччоли, счет, проводка, план счетов, системные и операционные объекты, клиент-сервер, стандартизация задач бухгалтерского учета.
Общие положения
В сегодняшней экономике особое значение приобретает такое явление, как стандартизация разных сторон экономической деятельности — от технических параметров аппаратного обеспечения и условий производства до контроля качества продукции и обеспечения безопасности в самых разных аспектах. Некоторые стандарты, называемые стандартами de facto, сложились в результате конкуренции стандартов, предложенных действующими на рынке компаниями, другие — были разработаны целевым порядком государственными институтами стандартизации или сообществами коммерческих и некоммерческих организаций. В данной статье предложен подход к стандартизации одного узкого направления деятельности,
которое сегодня оказалось вне программ стандартизации.
Таким направлением является область разработки автоматизированных систем бухгалтерского учета (АСБУ). В данном случае речь идет не о методиках разработки программного обеспечения или стандартах бухгалтерского учета, а непосредственно о типовом решении задачи бухгалтерского учета на базе средств вычислительной техники.
Стандартизация любого показателя означает, что некоторое конкретное значение этого показателя принимается в качестве эталонного. В случае стандартизации решения учетной задачи на предприятиях стандартом будет какое-то конкретное решение, которое, кроме решения самой задачи, должно для целей внедрения в массовых масштабах удовлетворять следующим требованиям:
• быть максимально простым для исполнения и эксплуатации;
• быть приемлемым по финансовым соображениям;
• быть способным приспосабливаться к конкретным условиям эксплуатации;
• быть стабильным, т. е. относительно независимым от законодательных актов, решений регулирующих органов, концепций хозяйствования и т. д.
Вполне может оказаться, что часть или даже все эти условия окажутся невыполнимыми, тем не менее опыт реально работающих АСБУ позволяет надеяться, что можно подобрать такое решение, которое будет, по крайней мере, приблизительно удовлетворять сформулированным условиям.
Для формулировки стандартного решения задачи необходимо, прежде всего, классифицировать саму задачу, т. е. отнести ее к некоторому классу более общих задач, и указать условия, выделяющие данную задачу из этого общего класса. Вообще говоря, сам вопрос классификации не имеет тривиального решения, так как в общем случае невозможно определить, какой признак является главным, а какой — второстепенным. Поэтому, прежде чем сформулировать концепции подхода к стандарту, необходимо рассмотреть вопросы, которые помогут выделить существенные для классификации признаки задачи: 1) предмет задачи учета;
2) существующие решения;
3) выгоды и недостатки этих решений;
4) свойства задачи, позволяющие ее автоматизировать.
Необходимо также рассмотреть особенности задачи в современных условиях перехода на Международные стандарты финансовой отчетности (МСФО).
Обсуждение этих вопросов должно обосновать предлагаемые подходы к стандартизации АСБУ. Здесь необходимо подчеркнуть, что хотя в общем случае решений (помимо предлагаемого), потенциально способных быть принятыми в качестве стандарта, может быть несколько, авторы оставляют за рамками данной статьи как сами альтернативные решения, так и обсуждение их преимуществ и недостатков.
Предмет стандартизации
Основную цель бухгалтерского учета можно кратко сформулировать так: знать, что происходит на предприятии. Согласно сегодняшним представлениям о деятельности предприятия, эта деятельность осуществляется по трем направлениям:
1. Операционная деятельность по созданию ценностей. При этом оказываемые услуги рассматриваются наравне с создаваемыми ценностями.
2. Инвестиционная деятельность по поводу вложения активов.
3. Деятельность по привлечению финансовых и иных ресурсов.
Другой взгляд на деятельность предприятия состоит в представлении о потоках ценностей между предприятием и контрагентами либо внутри предприятия. Существуют и другие концепции и модели деятельности предприятия, но как бы она ни рассматривалась, в любом случае подразумевается или прямо рассматривается обмен ценностями между предприятием и контрагентами либо переход ценностей из одного вида в другой. Поэтому можно говорить о движении ценностей вообще, и именно движение ценностей, а также их состояние в заданные моменты времени интересуют пользователей, имеющих отношение к учету.
Исходя из изложенного, можно сформулировать задачу учета в самом общем виде как регист-
рацию движения всех ценностей на предприятии безотносительно концепции его функционирования. Если движение будет зарегистрировано, то руководство предприятия, да и любое заинтересованное лицо, если ему будет предоставлена информация, сумеет проанализировать его и аргументированно принять решение. Можно конкретизировать регистрацию движения ценностей следующим образом: движение ценностей необходимо зарегистрировать в таком виде, чтобы было возможным предоставить отчетную информацию в том виде, который требуется или может потребоваться заинтересованным пользователям.
Однако, несмотря на то, что в настоящее время известны конкретные виды отчетности, которые необходимы заинтересованным пользователям, предусматривать их получение в стандартной автоматизированной системе неверно, так как это ставит стандарт в зависимость от видов отчетности, т. е. делает его нестабильным. Напротив, необходимо предусмотреть в стандарте способность приспосабливаться к возможному изменению требований заинтересованных субъектов. Это означает, что регистрируемые параметры, по крайней мере в существенной для законодательства части, не должны быть элементом стандартизации.
Кроме того, встает вопрос о достоверности данных, так как любая информация является информацией только тогда, когда она достоверна. Достоверна в том смысле, что ее пользователь должен быть уверен, что ввод информации выполнял человек, ответственный за это1. С другой стороны, лицо, ответственное за предоставление информации, должно быть уверено в том, что получатель не просматривает конфиденциальную информацию, не предназначенную ему. Поэтому любая система учета должна иметь возможность ограничить просмотр и изменение информации.
Таким образом, для целей стандартизации можно сформулировать задачу учета в следующем виде:
1 Мы не рассматриваем достоверность в смысле правдивости отражения действительных свойств учитываемых предметов и явлений, так как контроль за правильностью не является частью задачи учета. Это самостоятельная задача, относящаяся к области управления рисками, и она не попадает в рамки настоящей статьи.
1) должна быть возможность регистрации фактов движения ценностей;
2) должна быть возможность изменения набора атрибутов этих фактов;
3) должна быть возможность изменения способа отображения этих атрибутов;
4) должна быть возможность ограничения доступа на просмотр и изменение как отдельных атрибутов целиком, так и в соответствии с конкретными значениями этих атрибутов.
Регистрация фактов движения ценностей обеспечит реализацию учета в общем смысле. Возможность изменения набора атрибутов этих фактов и возможность изменения способа отображения этих атрибутов обеспечат приспособляемость учета к требованиям разных социальных агентов. Возможность ограничения доступа оградит информацию от несанкционированного вмешательства.
Несмотря на то, что сформулированную задачу можно решать разными способами, в настоящее время эксплуатируется только один вариант, принципы которого изложены Лукой Паччоли [1]. Этот вариант состоит в следующих положениях и элементах:
• используется понятие «счет», характеризующее некоторым образом свои или контрагентские ценности или обязательства;
• регистрация фактов движения ценнос-тей — для этих фактов используется понятие «проводка» — выполняется как пара записей, имеющих по два реквизита — сумму и счет. Сумма в обеих записях совпадает по абсолютной величине и различается по знаку, а счет различается;
• возможность изменения набора атрибутов этих фактов обеспечивается введением новых счетов.
Таким образом, технология учета по плану счетов основана на предположении, что учитываемые признаки финансовых и хозяйственных операций отражаются как номера счетов в плане.
В существующих АСБУ приведенные принципы реализованы всегда. В этом виде они предусмотрены в законодательных актах [2], регламентирующих ведение бухгалтерского учета, и обеспечивают получение отчетности, связанной с остатками и оборотами по счетам.
Такая система учета обладает определенной приспособляемостью к появлению необходимости учитывать новые атрибуты операций благодаря вводу в план новых счетов.
Тем не менее приспособляемость плана счетов к учету вновь появляющихся признаков оказывается ограниченной, так как одна и та же реальная финансовая или материальная операция может характеризоваться с разных сторон, и учет разных комбинаций характеристик приводит к необходимости дробить счета на множество подсчетов для каждого набора значений выбранных признаков. В рамках подхода с использованием утвержденного плана счетов это возможно сделать путем регламентирования правил формирований номера счета. Самый естественный вариант—это увязать учитываемый признак с позицией цифр в номере счета, т. е. возникает необходимость стандартизации позиционирования учетных признаков в номере счета. Для предприятий такая регламентация действует только в отношении счетов верхнего уровня.
Кроме необходимости введения громоздкого плана счетов, ограниченность подхода с использованием единого плана счетов проявляется еще и в том, что правила бухгалтерского учета фактически определяются разными ведомствами и подразделениями самого предприятия. Их может не интересовать конкретный номер счета, который должен учесть тот или иной признак финансовой или материальной операции, соответственно, эти номера вообще не вводятся. Например:
• признаки налоговых платежей устанавливаются, в конечном счете, налоговыми органами и регистрируются в виде специальных реквизитов в платежных документах;
• подозрительные и опасные для самого предприятия признаки операций устанавливаются подразделениями экономической безопасности и внутреннего аудита;
• признаки операций с особо важными клиентами устанавливаются руководством предприятия и т. д.
Попытки отразить все учитываемые признаки на специальных счетах в рамках общего плана счетов предприятия не только приводят к громоздкому плану счетов, но могут просто противоречить установленным правилам ведения бухгалтерского учета.
Причиной противоречий является, например, то, что продажа акций некоторого предприятия самому предприятию является операцией, не стандартной относительно передачи прав владения акциями от одного лица к другому, так как внешний владелец акций является инвестором, а владелец-банк — нет. Преодоление таких нестандартных ситуаций в рамках одного плана счетов приведет к крайне разветвленному плану, так что бухгалтерская информация просто не будет поддаваться анализу.
Таким образом, план счетов оказывается довольно ограниченным инструментом учета разнообразных атрибутов финансовых и материальных операций. Решить эти противоречия можно введением учета по нескольким планам счетов одновременно, т. е. при характеристике операции устанавливать по каждому направлению свои значения признаков. Более того, существующая практика ведения дополнительных таблиц внутри организаций, предназначенных специально для получения информации вне основного плана счетов, фактически представляет собой ведение нескольких параллельных планов счетов, так как по крайней мере формально план счетов представляет собой не что иное, как список признаков проводок.
Кроме этих принципов, всегда реализуются следующие свойства, зависящие только от автоматизированной системы:
• возможность изменения способа отображения атрибутов, относящихся к одной записи «сумма — счет»;
• возможность ограничения доступа к записям ставится в зависимость от счета, суммы и остальных атрибутов, относящихся к одной записи «сумма — счет».
Эти свойства обеспечивают соответственно приспособляемость учета к требованиям разных социальных агентов и ограничение от несанкционированного доступа.
В результате, при существующем решении возникают определенные трудности. Например, фундаментальным положением бухгалтерского учета является наличие таблицы остатков по счетам и таблицы проводок. Эти две таблицы однозначно связаны друг с другом, и по информации, содержащейся в любой из них, можно вычислить информацию в другой. Такая взаимосвязь
порождает проблемы на уровнях технологии, производства и поддержки, администрирования и эксплуатации (табл. 1).
Концепция стандартизации
Обобщенно существующее решение можно охарактеризовать как решение, при проектировании которого законодательные инструкции использовались в качестве элементов и сущностей АСБУ. Его главные выгоды состоят в подразумеваемом предположении, что бухгалтеры и финансисты сумеют эффективно воспользоваться той автоматизированной системой, которая непосредственно реализует их инструкции и использу-
Трудности суще<
емое ими законодательство. Главный недостаток такого подхода — отсутствие доказательств правильности подхода при программной реализации инструкций и законодательства. Из этого недостатка вытекают все внутренние сложности и проблемы АСБУ.
Чтобы оценить адекватность подхода к решению задачи учета, необходимо проанализировать экономическую и юридическую суть базовых понятий бухгалтерского учета и их техническую реализацию.
Понятия «счет» и «проводка». При всей очевидности понятий «счет» и «проводка» необходимо иметь в виду, что они понимаются в смысле
Таблица 1
'ющего решения
Фактор Характеристика
Проблемы технологического уровня Из практики учета вытекает требование о ведении нескольких планов счетов, но если АСБУ одноплановая, то это просто невозможно, а в многоплановой системе выполнение финансовых транзакций оказывается слишком медленным из-за необходимости коррекции остатков по каждому плану счетов
Проблемы уровня производства и поддержки Автоматизированная система бухгалтерского учета с большим числом используемых таблиц и объектов, очевидно, сложнее в разработке, модификации и сопровождении. Это является источником внутренних ошибок системы, а также ведет к удорожанию автоматизированного комплекса в целом
Проблемы уровня администрирования На этом уровне возникают ошибки, связанные с неверной постановкой задачи. Наличие отдельной таблицы остатков по счетам и таблицы проводок разработчики связывают с предоставлением прав пользователям на них независимо друг от друга. Это связано с тем, что разработчики рассматривают и проводки, и счета как самостоятельные объекты со своими свойствами. Подразумевается, что должна быть предоставлена возможность одним пользователям права на свойства счетов, а другим — на свойства проводок. В результате система допускает несогласованное предоставление прав на счета и проводки*. Таким образом, ответственность за согласование при предоставлении прав ложится на администраторов, что является источником ошибок. Такие ошибки приписывают некомпетентности администраторов, хотя в первую очередь они являются следствием некомпетентности разработчиков, так как представление о счетах как о самостоятельных объектах в смысле учета неверно. Это предупреждается путем найма высококвалифицированных администраторов, что также ведет к удорожанию эксплуатации АСБУ в целом
Проблемы уровня эксплуатации На этом уровне возникают проблемы безотказности и быстродействия. Вследствие аппаратных и программных сбоев прерывание транзакции между изменениями в разных таблицах может приводить к искажению информации, поскольку выполнение каждой финансовой транзакции требует внесения изменений и в таблицу остатков по счетам, и в таблицу проводок. Такие ошибки предупреждаются путем использования систем управления базами данных (СУБД) с поддержкой транзакций, что ведет к удорожанию АСБУ в целом и замедлению исполнения операций. Замедление исполнения операций, в свою очередь, компенсируется повышением производительности аппаратуры, что снова ведет к удорожанию автоматизированного комплекса в целом
Несогласованность прав на счета и проводки может проявиться, например, таким образом: пусть пользователю для выполнения функций предоставили права на счета, но не на проводки. Но, поскольку остатки на счетах однозначно связаны с проводками, этот пользователь может вычислить и движение, т. е. проводки. В результате получается, что предоставление прав на счета фактически предоставляет права на проводки.
скорее бытовом, чем научном. В частности, в законодательстве России термин «счет» имеет достаточно расплывчатое определение и полагается априорно известным понятием. Англоязычный термин account, производный от count — «считать», означает нечто считаемое, что также не может быть признано за определение. Таким образом, реализация при автоматизации учета понятия «счет» как некоторой самостоятельной сущности, как индивидуально существующего объекта, вообще говоря, не имеет научного обоснования. Интуитивное понимание счета состоит в представлении о количестве денег или других материальных ценностей, которыми распоряжается одно лицо, но находящихся у другого лица. Это представление формулируется следующим образом: первое лицо держит (имеет) счет у второго лица. Другой вариант формулировки: второе лицо открыло счет для первого лица. Такая формулировка создает видимость, что счет — это некоторый индивидуальный объект, хотя в действительности это только одна из характеристик количества денег или ценностей, отражающая экономические и юридические отношения двух лиц. Возможно, это противоречие является первоначальной причиной внутренних сложностей существующих реализаций учета. В частности, если учесть, что отчеты, которые интересуют пользователей бухгалтерской отчетности, характеризуют факты деятельности предприятия, то получение таких отчетов из таблицы счетов приравнивает счета к финансовым фактам. Это нельзя признать правильным, так как счета являются только качествами, свойствами фактов. Придание счетам статуса фактов методологически противоречиво, потому что счет, являясь отношением, не имеет вещественного выражения, а статус факта приписывает ему вещественные признаки, т. е. получается, что счет одновременно имеет вещественное выражение и не имеет его.
Понятие «проводка» также не имеет официального определения. В отношении этого термина, по-видимому, нет методологических противоречий. Интуитивное понимание проводки как переноса суммы с одного счета на другой, вообще говоря, некорректно, если счет не рассматривается как отношение (такое понимание предполагает, что счет и проводка — это, соответственно, факт
и его характеристика. В действительности фактом является проводка, а счет — его характеристикой.), но не порождает противоречий. Что же такое проводка? Поскольку нахождение денег, принадлежащих одному лицу (кредитору), у другого (дебитора) можно характеризовать со стороны и первого, и второго лица, значит, проводка характеризует одновременное изменение суммы первого и обязательства второго. Согласно такому представлению, обоснованному Лукой Паччоли [1], проводка — это один из четырех фактов:
1) увеличение суммы и обязательства соответственно кредитора и дебитора;
2) уменьшение суммы и обязательства соответственно кредитора и дебитора;
3) увеличение и уменьшение сумм соответственно одного и другого кредитора;
4) увеличение и уменьшение обязательств соответственно одного и другого дебитора.
Таким образом, «проводка» является синонимом финансового факта, который характеризуется по крайней мере четырьмя признаками: суммой, двумя счетами и не упомянутым ранее моментом времени.
План счетов и таблица остатков на счетах. Поскольку счет не является самостоятельной сущностью, необходимо пересмотреть технологический смысл таблицы, содержащей план счетов, и смысл таблицы остатков на счетах.
План счетов — это список признаков, интересующих пользователей отчетности. Любой список признаков, если эти признаки проводок интересуют в каком-либо отношении некоторого пользователя бухгалтерской отчетности, является планом счетов по соответствующему направлению, а каждый признак этого списка является определенным счетом. В частности, можно доказать, что для любого произвольного списка признаков выполняется фундаментальное свойство плана счетов — равенство суммарных дебетовых и кредитовых оборотов по всем имеющимся в этом списке счетам. Для полноты картины следует заметить, что второе свойство планов счетов — равенство суммарных остатков активных и пассивных счетов, — тоже считающееся фундаментальным, на самом деле является математическим следствием равенства суммарных дебетовых и кредитовых оборотов. То
есть фундаментальным свойством планов счетов является только последнее равенство.
Остаток на каждом счете — это итог, полученный путем арифметического сложения значения признака «сумма», для проводок, имеющих данный счет в качестве одного из двух признаков «счет». Суммирование выполняется по всем проводкам с данным значением признака «счет» с учетом знака в зависимости от положения этого признака, взятым от начала работы предприятия до заданного момента времени. То есть таблица остатков на счетах является таблицей промежуточных значений, технологическое назначение которой состоит только в быстром получении итоговых значений признака «сумма»2.
Дебетовые и кредитовые обороты. Аналогично счетам проводка не является характеристикой счета, поэтому необходимо пересмотреть технологический смысл таблицы проводок.
В технологии, разработанной Лукой Паччо-ли, проводка регистрируется как пара записей в таблице счетов, и этой информации, в принципе, достаточно для учета, т. е. специальной таблицы проводок вообще не нужно, так как реквизиты любой проводки можно вычислить из реквизитов
2 Очевидно, что в условиях, когда Лука Паччоли сформулировал принцип двойной записи для целей учета, другого
варианта для подсчета итоговых сумм просто не могло быть.
Те условия можно охарактеризовать следующим образом:
• вместо пересчета итогов при просмотре был предусмотрен пересчет по каждому задействованному счету по мере регистрации проводок, так как при необходимости просмотра итога пересчитывать все увеличения и уменьшения сумм с начала учета вручную было невозможно; косвенно это соображение подтверждается введением проводок сторно;
• такой способ учета подходит только для случая, когда регистрацию проводок по одному счету в заданный момент времени выполняет только одно лицо, потому что при одновременной регистрации проводок несколькими лицами результат пересчета итога может оказаться некорректным;
• такой способ учета приспособлен для получения только текущей информации, так как в случае обнаружения ошибки при регистрации какой-либо прежней проводки объем пересчета может оказаться слишком большим для выполнения;
• такой способ учета мало приспособлен для учета проводок по большому списку разноплановых и взаимопе-ресекающихся признаков. По-видимому, самому Луке Паччоли было достаточно разреза по контрагентам и срокам кредитов.
соответствующих записей в таблице счетов. Тем не менее во всех правилах учета и во всех АСБУ предусмотрено ведение соответственно специальных дел и таблиц, в которые заносятся первичные документы. Фактически это правило диктуется не самим учетом, а необходимостью:
• для бухгалтерского дела — наличия возможности проводить проверки и аудит;
• для автоматизированных систем — возможности восстановить таблицу остатков, так как именно таблица остатков является в существующих автоматизированных системах источником данных для отчетов.
То есть для бухгалтерского дела учет первичных документов является требованием контролирующих организаций, а в АСБУ это всего лишь резервная копия данных. Однако такой статус таблицы проводок принципиально неверен, так как именно таблица проводок является списком анализируемых финансовых фактов. Даже когда отчеты получаются из таблицы промежуточных результатов (таблицы остатков), эти отчеты верны потому, что таблица остатков в действительности является отражением таблицы проводок.
Поскольку все финансовые операции имеют денежное выражение, индивидуальная проводка характеризуется признаком «сумма». Обозначение ее как дебетовой или кредитовой подчеркивает первичность таблицы остатков в технологии двойной записи. В действительности дебетовые и кредитовые обороты являются характеристикой положения признака «счет» в паре этих признаков, относящихся к одной проводке. Эта характеристика является настолько естественной, что в АСБУ делается отступление от строгого следования технологии получения отчетов только из таблицы счетов. Вместо этого отчеты, связанные со списками операций, например выписки, делаются по таблице проводок, т. е. в автоматизированных системах допускается некоторая непоследовательность в реализации принятой технологии учета.
Таким образом, дебетовые и кредитовые обороты — это характеристика взаимного соотношения признаков проводки, а именно: признака «сумма» и каждого из двух признаков «счет».
Техническая реализация бухгалтерских категорий. В АСБУ она не имеет принципиальных
ограничений, и главная задача при автоматизации — это обоснованный выбор технологии автоматизации. Однако современные автоматизированные системы, имея огромный запас производительности, безотказности и безошибочности, тем не менее используются на отдельных участках, более того, в отдельных операциях, т. е. некомплексно. Очевидно, что это снижает их потенциальную эффективность. Авторы считают, что это есть следствие отсутствия четкой формулировки, показывающей, в каких именно типах операций состоит преимущество компьютерных технологий. То есть имеет место ситуация, аналогичная той, когда есть потребность в некотором предмете или состоянии, есть понимание его правильности и принципиальной достижимости, есть необходимые ресурсы для его достижения, но нет предусмотренных механизмов получения требуемого предмета или перехода в требуемое состояние. В результате ресурсы используются несистемно, нецеленаправленно, непоследовательно, что влечет за собой неэффективность их использования и фактическое недостижение требуемого предмета или состояния.
В области автоматизации учета требуемым состоянием является автоматизированный учет, необходимыми ресурсами являются аппаратные и программные средства, а механизмами достижения результата (кроме слишком общего понятия «технология автоматизации»), по мнению авторов, должны быть следующие технические решения:
1) поддержка пакетов проводок, т. е. переход от регистрации индивидуальных фактов переносов денежных средств между счетами к регистрации финансовых транзакций;
2) автоматический ввод данных и его выполнение с произвольного устройства ввода и аналогичное решение в отношении вывода данных;
3) автоматическая генерация проводок или пакетов проводок при наступлении определенных событий, в том числе организованы серверы, управляющие проводками или пакетами проводок, серверы регламентных работ и других регулярных операций;
4) электронный документооборот, в том числе организованы серверы отчетов постоянной готовности и электронно-цифровая подпись документов;
5) автоматический анализ данных в разных отношениях (корректность, достоверность, актуальность, безопасность, несанкционированный доступ, допустимость и т. д.), в том числе организованы внутрикорпоративные аудиторские и аналитические серверы;
6) вытекающая из высокого быстродействия вычислительной техники пониженная необходимость в хранении вычисляемых промежуточных данных, так как конечные отчеты возможно получать непосредственно из первичных источников.
Вообще говоря, при автоматизации учета делаются попытки использования этих технических решений, но эти попытки носят несистемный характер. Несистемность использования проявляется в том, что они применяются лишь эпизодически в самих АСБУ, и в том, что применяются только отдельные решения, а не весь комплекс перечисленных преимуществ автоматизированных систем.
Новый подход к решению задачи учета требует выполнения описания назначения системных и информационных объектов, концепции способа доступа к информации и концепции работы автоматизированной системы. Конкретные способы реализации этих концепций и структур объектов оставляются за разработчиками.
Системные и информационные объекты. Решение задачи учета закономерно вытекает из сущности фундаментальных понятий бухгалтерского учета «счет» и «проводка». Поскольку учетными фактами являются проводки, а счета являются только признаками каждой конкретной проводки, то в АСБУ должна быть предусмотрена только одна таблица, содержащая финансово значимую информацию3, — это таблица проводок.
Назначение столбцов таблицы проводок — место для хранения признаков конкретной проводки. По характеру задачи учета должны быть предусмотрены три типа признаков:
1) сущностные признаки — это показатели, ради которых ведется учет;
2) классифицирующие признаки — это показатели, при помощи которых ведется учет;
3 Под значимой информацией подразумевается информация о фактах деятельности предприятия, например оплата товара, обработка материалов и т. д.
Таблица 2
Типы признаков проводок
Назначение типа признаков Примеры признаков Лицо, изменяющее состав признаков (столбцы в таблице) Лицо, изменяющее значения признаков (поля в записях)
Сущностные признаки
Показатели, значения которых являются целью учета. Эти признаки отражают учетные факты Сумма полученного кредита, количество обработанного материала, единица измерения, признак открытия или закрытия счета Администраторы автоматизированной системы Пользователи автоматизированной системы
Классифицирующие признаки
Показатели, по значениям которых производится группировка проводок для целей учета (планы счетов) Группа доходов, код акционера, группа риска, номер картотеки, код Федеральной службы по финансовому мониторингу, налоговый признак Администраторы автоматизированной системы Пользователи автоматизированной системы
Инфраструктурные признаки
Показатели, по значениям которых производится группировка или классификация проводок для целей корректной работы автоматизированной системы Идентификатор проводки, идентификатор транзакции, идентификатор пакета, состояние записи, состояние проводки Разработчики автоматизированной системы Специальные пользователи автоматизированной системы, например системные серверы
3) инфраструктурные признаки — это показатели, которые обеспечивают работу автоматизированной системы.
При этом должна быть предусмотрена возможность изменения состава признаков первого и второго типов средствами АСБУ без привлечения разработчика. Более подробная характеристика этих типов приведена в табл. 2.
Ключевая концепция решения состоит в следующем: поскольку в учетных системах конечной информацией для анализа являются форматированные списки проводок с итогами4, то получение всей информации для анализа нужно производить из самой таблицы проводок без специальных таблиц для хранения промежуточных значений. Например, в таблицу проводок можно вводить записи, соответствующие открытию-закрытию счета, и, таким образом, получать из таблицы проводок даже информацию, не связанную с движением денежных или материальных средств.
Указанные в табл. 2 свойства таблицы проводок обеспечат принципиальную возможность решения первых трех подзадач задачи учета: регистрации фактов движения ценностей, изме-
4 В контексте настоящей статьи списки без итогов и только итоги рассматриваются как частные случаи списков
с итогами.
нения набора атрибутов этих фактов, изменения способа отображения этих атрибутов. Для решения четвертой подзадачи — ограничения доступа на просмотр и изменение информации — этой таблицы недостаточно, даже если учесть, что администраторы АСБУ будут иметь возможность ввести специальные поля в целях разграничения доступа к отдельным записям этой таблицы. Использование этих полей все равно будет связано с распределением прав путем введения записей в специальные таблицы распределения прав.
Вторая предусмотренная таблица — это таблица прав пользователей. Структура и способ представления информации в ней определяются разработчиками, но рекомендуется учесть следующие моменты:
• стиль изменения информации в таблице должен быть реализован в общем для АСБУ стиле, включая возможность экспорта во внешний файл и импорта из внешнего файла;
• наличие возможности увязывать пользователей со списком доступных столбцов и записей таблицы проводок, причем доступ к записям должен быть реализован путем увязки пользователей со списком диапазонов и масок значений в произвольных полях записей;
• определение групповых и индивидуальных прав.
Указанные свойства таблицы прав пользователей обеспечат принципиальную возможность ограничения доступа на просмотр и изменение как отдельных атрибутов целиком, так и в соответствии с конкретными значениями этих атрибутов.
Автоматизированная система бухгалтерского учета должна строиться на базе таблицы проводок и таблицы прав пользователей: пользователи автоматизированной системы при выполнении всех манипуляций с данными должны производить манипуляции только с данными этих двух таблиц, и все программные примитивы должны иметь в качестве входных и выходных аргументов только объекты уровня этих двух таблиц. Внутреннее представление этих таблиц определяется разработчиками, и не рекомендуется предоставлять пользователям средства управления объектами уровня более низкого, чем уровень таблицы проводок и таблицы прав пользователей, так как на более низком уровне нет объектов, отображаемых в бухгалтерские категории. В случае если по усмотрению разработчиков какая-то таблица будет состоять из нескольких таблиц5, то права на зависимую таблицу должны предоставляться автоматически и в соответствии с правами на основную таблицу.
Таблицы проводок и прав пользователей уже содержат информацию, достаточную для реализации учета, поэтому собственно учет состоит в манипуляциях с данными этих двух таблиц. Однако АСБУ еще должна иметь возможность введения таблиц-справочников и других дополнительных таблиц, назначение которых — оптимизация учета в соответствии с принципами управления реляционными базами данных, причем эту оптимизацию должны выполнять не разработчики, а администраторы. В отношении таких таблиц рекомендуется, чтобы присутствовали следующие таблицы:
• таблицы-справочники, являющиеся законодательно установленными классификаторами, например справочник кодов операций Федеральной службы по финансовому мониторингу, справочник адресов КЛАДР, справочники ОКАТО, ОКВЭД и т. п.;
• таблица операций (транзакций);
• таблица пакетов операций.
5 Например, какая-то часть полей будет вынесена в таблицу-справочник, а в основной таблице соответствующие значения будут заменены кодами.
Поскольку на учет при помощи АСБУ неизбежно накладываются особенности автоматизации, должна (ы) быть еще таблица (ы) — журнал работы.
С технологическим смыслом таблицы прав пользователей связан доступ к информации в любой таблице проводок через представление. Представление — это запрос к таблице, построенный на основе информации в таблице прав пользователей. Доступ к информации в любой таблице осуществляется исключительно через представление, прямой доступ не предусмотрен. Представление должно быть реализовано в рамках программной платформы, на которой строится учетная система. Например, если АСБУ строится на базе СУБД, то на уровне СУБД права должны предоставляться на запросы к таблицам, а не на сами таблицы6. В случае возникновения конфликта между правами пользователя на разные поля записи, если эти поля окажутся логически взаимосвязанными, конфликт должен разрешаться особой процедурой, связанной с таблицей. Примером конфликта прав может быть отсутствие доступа к полю идентификатора и разрешение на добавление записей в таблицу: конфликт заключается в необходимости внесения информации в поле идентификатора и отсутствие прав на такое действие. Разрешение этого конфликта должно выполняться специальной процедурой, например следующим образом: процедура генерирует новое значение идентификатора независимо от информации, введенной пользователем, а окончательная запись информации производится на основе данных, введенных пользователем и сгенерированных специальной процедурой. В целом способ разрешения конфликта определяется разработчиками, но может быть передан в ведение администратора.
Из доступа к информации в таблице через представление вытекает принципиальная необходимость клиент-серверной концепции при выполнении тех или иных действий: любое действие в системе долж-
6 Таким образом, запросы, изменяющие информацию
(удаление, изменение, вставка данных) для пользователей,
должны выглядеть как действия над тем объектом, к которому они имеют доступ, а техническая реализация этих действий не регламентируется и остается на усмотрение разработчиков.
но быть попыткой выполнения этого действия над представлением, а не над таблицей-источником.
Еще одно следствие, вытекающее из доступа к информации в таблице через представление, состоит в том, что любые программы и процедуры, изменяющие информацию, должны оперировать объектами, имеющимися в представлении.
Поскольку любое представление таблицы является не самодостаточной сущностью, а источником информации, в целях стандартизации доступа к информации, в таблице рекомендуется обеспечить следующий список стандартных свойств и реквизитов представлений таблиц:
• установка произвольного фильтра на доступные записи с возможностью запоминать персональные фильтры для последующего наложения на представление;
• занесение произвольного значения из допустимого диапазона в произвольное поле из доступных для записи в выбранных или всех строках представления. Возможность занесения значения, вычисляемого в процессе непосредственно операции занесения, оставляется на усмотрение разработчика;
• операция экспорта информации в произвольный приемник7 в соответствии с имеющимися шаблонами, относящимися к данному представлению, с возможностью создавать персональные шаблоны;
• операция импорта информации из соответствующим образом структурированного произвольного источника8.
В соответствии с базовой концепцией АСБУ должна иметь три уровня:
• программный — относится к программной реализации учетной системы разработчиками и должен обеспечить работоспособность объектов, находящихся на концептуальном и интерфейсном уровнях без обращения к объектам самого программного уровня;
• концептуальный — относится к технологии реализации учета и представляет собой объ-
7 Под приемником понимается файл операционной системы, порт ввода-вывода или внешняя программа, обрабатывающая информацию.
8 Под источником аналогично приемнику понимается файл операционной системы, порт ввода-вывода или внешняя программа, обрабатывающая информацию.
екты с их атрибутами, которыми оперируют потребители;
• интерфейсный — относится к способу управления объектами концептуального уровня. В соответствии с базовой концепцией разграничение доступа к информации должно осуществляться путем предоставления прав на представления. Рекомендуемые стандартные атрибуты доступа — это «чтение» и «запись». По усмотрению разработчиков список атрибутов доступа может быть расширен9. Не рекомендуется осуществлять разграничение доступа путем предоставления прав на исполнение тех или иных процедур.
И регистрация пользователей, и предоставление прав должны осуществляться в рамках программной платформы, на которой строится АСБУ10.
Предложенная базовая концепция учетной системы регламентирует реализацию объектов, содержащих информацию, которая интересует конечных потребителей. Кроме этого, авторы считают необходимым регламентировать состав функциональных блоков. В соответствии со способом доступа к информации АСБУ должна быть реализована в концепции «клиент-сервер» и содержать следующие функциональные блоки (табл. 3):
• внутренний блок, состоящий:
— из сервера, управляющего таблицей проводок;
— из серверов отчетов постоянной готовности;
— из внутрикорпоративных аудиторских и аналитических серверов;
— из серверов регламентных работ и других регулярных операций;
• сервер ввода-вывода данных;
• клиентские программы.
Среди характеристик, не относящихся к собственно технологии автоматизации учета, авторы считают полезными следующие дополнительные модули:
• подсистему стандартного описания и генератор отчетов;
9 Примеры расширенных атрибутов — «добавление», «удаление», «передача прав» и др. Если же в учетной системе список атрибутов доступа будет ограничен только «чтением» и «записью», то атрибут «запись» должен включать «добавление» и «удаление».
10 То есть права и пользователи должны быть зарегистрированы в СУБД.
Таблица 3
Функциональные блоки АСБУ
Компонент Характеристика
Сервер, управляющий таблицей проводок Читает или изменяет информацию в таблице проводок в ответ на запросы. Запросы получает от сервера ввода-вывода данных. При получении запроса проверяет права источника запроса на затребованное действие и при достаточности прав выполняет его. Результаты запроса возвращает серверу ввода-вывода данных
Серверы отчетов постоянной готовности С заданной периодичностью создают отчеты, выбранные для автоматического создания в заданном формате. Создаваемые отчеты передаются внешним системам. Рекомендуемые дополнительные свойства таких серверов: • принудительный запуск в произвольное время; • когда это оправданно, модификация только измененной части отчета либо полное пересоздание отчета
Внутрикорпоративные аудиторские и аналитические серверы Выполняют проверки информации на соответствие заданным правилам, ограничениям, соотношениям и т. п. Результаты проверок передаются журналирующему серверу
Серверы регламентных работ и других регулярных операций Выполняют специальные работы, предусмотренные правилами учета или внутренними правилами предприятия. Рекомендуемые дополнительные свойства таких серверов: • принудительный запуск в произвольное время; • запуск при наступлении заданного события; • полное либо частичное повторение работы; • свойства в зависимости от характера работы Рекомендуемый обязательный сервер этой группы — журналирующий сервер
Сервер ввода-вывода данных Обеспечивает прием запросов на изменение информации в таблице проводок от клиентов или запросов на чтение информации. При получении запроса проверяет электронную подпись отправителя запроса и уникальность* запроса, при успешной проверке принимает запрос. Результаты проверки и запрос передаются журналирующему серверу, затем запрос в соответствии с параметрами, приписанными отправителю, приводится к стандартному виду и передается серверу, управляющему таблицей проводок. Ответ от него форматируется в соответствии с параметрами, приписанными отправителю, подписывается и возвращается отправителю запроса. В связи с фактическим превращением в стандарт IP-сетей и сервисов на основе протокола TCP/IP рекомендуется, чтобы сервер ввода-вывода данных состоял из двух компонентов: компонента, отвечающего за файловый ввод-вывод, и компонента, реализованного в виде сервиса**
Клиентские программы Создают запросы, подписывают и передают их серверу ввода-вывода данных в виде файлов или по IP-каналу. У полученных ответов проверяют электронную подпись отправителя ответа. Дальнейшая обработка зависит от конкретных условий эксплуатации. Для целей унификации рекомендуется автоматизированные рабочие места работников предприятия создавать в виде клиентских программ. Это означает, что работа в учетной системе не должна осуществляться исключительно через автоматизированные рабочие места, созданные разработчиками учетной системы, а они должны быть равноправными пакетами в ряду клиентских программ, созданных разными производителями
* Под уникальностью подразумевается уникальность во времени. Целью проверки является предотвращение обработки тех запросов, которые пришли повторно. Например, если отправитель запроса из-за сбоя не получил подтверждения получения запроса и послал запрос повторно, у получателя может оказаться два идентичных запроса. Для запросов на чтение это может привести к мелким неприятностям, например, повторному ответу большого объема, а для запросов на изменение это может привести к выполнению неправильных действий.
** То есть клиентская программа должна обращаться к нему по 1Р-адресу и номеру порта.
Таблица 4
Регламентация элементов автоматизированной системы
Элемент Способ Цель
Концепция автоматизации технологии учета Стандартизация архитектуры базы данных АСБУ и набора объектов, которыми она оперирует • Формулировка критериев правильности работы и устройства автоматизированной системы для осознанного выбора из предлагаемой продукции или для постановки задачи подразделениям автоматизации. • Методическая основа для финансовой оценки предлагаемого программного обеспечения
Список компонентов автоматизированной системы Стандартизация набора компонентов автоматизированной системы и разграничение обязательных и необязательных компонентов
Уровни абстракции данных Стандартизация элементов автоматизированной системы, с которыми работают конечные потребители • Понимание технологии работы АСБУ конечными потребителями и возможность проверки правильности реализации алгоритмов. • Возможность модификации АСБУ без привлечения разработчиков
Возможности сообщения с внешними системами Стандартизация каналов сообщения с внешними системами Возможность интеграции АСБУ с другими системами потребителей
Отдельные элементы интерфейса Стандартизация существенных для работы общих операций Формулировка обязательных операций, обеспечивающих удобства потребителей
• подсистему стандартного описания и генератор клиентских экранных форм.
Эти модули являются необязательными и вводятся в состав АСБУ по усмотрению разработчиков.
Авторы считают нецелесообразным вводить в состав АСБУ средства, дублирующие стандартные средства операционной системы, и средства специализированных пакетов: файловый диспетчер, почтовый диспетчер и клиент, развитые текстовый и табличный редакторы и т. п.
Таким образом, представленная концепция стандартной АСБУ регламентирует способ реализации бухгалтерских правил аппаратно-программными средствами современных компьютерных технологий. Главные положительные моменты такой регламентации перечислены в табл. 4.
Заключение
Кроме выгод стандартизации, авторы считают, что представленная концепция обеспечивает возможность качественно и прозрачно реализовать и требования к системам АСБУ разных социальных агентов, и настраиваемость системы, построенной в соответствии с данным стандартом, на любые законодательные и технико-экономические условия.
Настоящую концепцию, конечно, нельзя рассматривать как окончательный вариант проекта
стандарта, так как в ней отсутствуют следующие элементы, важные с точки зрения стандартизации:
• протоколы обмена информацией между серверами внутреннего блока;
• протоколы обмена информацией между сервером ввода-вывода и внешними программами;
• правила описания отчетных и экранных форм.
Вероятно, есть и другие элементы стандартизации, которые оказались вне данной статьи, однако все они закономерно вытекают из концепции автоматизации, предложенной в настоящей статье, и положений стандарта, на которых было сосредоточено внимание.
Конечным практическим результатом принятия стандарта АСБУ авторы считают общедоступный документ, который был бы для руководителей организаций руководством при постановке задачи подразделениям автоматизации, а при приобретении программного обеспечения сторонних производителей — руководством для аргументированной оценки предлагаемого программного обеспечения в зависимости от степени его соответствия положениям стандарта. Кроме того, этот документ был бы для производителей бухгалтерского программного обеспечения не только постановкой задачи, но и основой рейтинговых оценок их продукции.
Особенности стандарта применительно к МСФО. Как заявляет разработчик МСФО «Фонд МСФО» (IFRS Foundation) [3], те стандарты, которые называются МСФО, являются не предписанием для ведения учета, а рекомендациями высшим руководителям предприятий предоставлять отчетность в определенном виде, который, по мнению разработчиков МСФО, будет понятным широкому кругу вероятных инвесторов. Более того, эти рекомендации вообще не дают никаких предписаний относительно подробности публикуемой отчетности — это прерогатива исключительно руководства предприятий. В этом смысле МСФО никак не привязан к той или иной методике учета, а звучащие в СМИ или в рекламе программных пакетов учета заявления о «соответствии МСФО» или «реализации МСФО» в лучшем случае можно рассматривать только как рекламу в стиле «Мы — номер один». Однако можно говорить о соответствии базовым принципам механизма формирования отчетности. При ближайшем рассмотрении этих базовых механизмов видно, что эти механизмы, а именно: выбор руководством уровня детальности и набора публикуемых показателей — в точности соответствуют изложенной нами обобщенной задаче учета, за исключением технологического требования. Повторим ключевые вопросы обобщенной задачи учета:
1) должна быть возможность регистрации фактов движения ценностей;
2) должна быть возможность изменения набора атрибутов этих фактов;
3) должна быть возможность изменения способа отображения этих атрибутов.
Так как мы заявляем о решении этой задачи в рамках предлагаемого стандарта, то изложенная концепция стандартизации бухгалтерского учета есть не что иное, как изложение МСФО в терминах решения задачи автоматизированной системы учета. Таким образом, если будет создана АСБУ в соответствии с предлагаемым стандартом, она по сути будет автоматизированной версией МСФО,
так как предлагаемый авторами стандарт в полном согласии с МСФО не устанавливает никаких национально ориентированных требований или условий.
Отдельно нужно остановиться на этапе перехода на МСФО. Так как предлагаемый стандарт не накладывает национально ориентированных ограничений, то реализация, скажем, российских правил бухгалтерского учета в соответствии с предлагаемым стандартом в момент перехода на МСФО потребует просто отказа от одних признаков и принятия других, а возможность этого преобразования прямо заложена в стандарте. То есть никаких перетрясок и сложных «переходов» не потребуется — все будет сделано в рамках и средствами самой АСБУ. Более того, на время непосредственно переходного периода оба учета могут сосуществовать в рамках одной и той же АСБУ наравне, никак не конфликтуя друг с другом, так как признаки по международным и российским правилам бухгалтерского учета с точки зрения данного стандарта будут совершенно равноценны и взаимонезависимы.
Таким образом, авторы полагают, что принятие предлагаемого стандарта не только полезно с точки зрения стандартизации автоматизированных систем, но и прекрасно соотносится с существующими стандартами ведения бухгалтерского учета и отчетности.
Список литературы
1. Лука Паччоли. Сумма арифметики, геометрии, учения о пропорциях и отношениях. Часть первая. Отдел 9. Трактат IX. О счетах и записях / пер. Э. Г. Вальденберга. Режим доступа: http://www. supertrader. ru/books/books1-cut/lukasod. htm.
2. О бухгалтерском учете: Федеральный закон от 21.11.1996 129-ФЗ (в редакции от 28.11.2011) // Информационно-справочная система «Консуль-тантПлюс».
3. Официальный сайт IFRS Foundation — http://www. ifrs. org/Home. htm.