Московский государственный университет печати

Шуремов Е.Л., Умнова Э.А., Воропаева Т.В.


         

Автоматизированные информационные системы бухгалтерского учета, анализа, аудита

Учебное пособие для вузов


Шуремов Е.Л., Умнова Э.А., Воропаева Т.В.
Автоматизированные информационные системы бухгалтерского учета, анализа, аудита
Начало
Печатный оригинал
Об электронном издании
Оглавление
1.

Раздел 1. Основы построения автоматизированных информационных систем бухгалтерского учета

1.1.

Глава 1. Понятие автоматизированных информационных систем бухгалтерского учета

1.1.1.

Автоматизированная информационная система бухгалтерского учета в управлении экономическим объектом

1.1.2.

Структура учетной информации

1.1.3.

Информационный процесс бухгалтерского учета и информационные технологии

1.1.4.

Обеспечивающие компоненты АИС-БУ

1.1.5.

Автоматизированное рабочее место бухгалтера

1.1.6.

Концептуальная модель обработки данных в АИС-БУ

1.1.7.

Компьютерная форма бухгалтерского учета

1.1.8.

Вопросы для самоконтроля

1.2.

Глава 2. Классификация автоматизировании информационных систем бухгалтерского учета

1.2.1.

Подходы к классификации АИС-БУ

1.2.2.

Развернутая классификация АИС-БУ

1.2.3.

Интегральная классификация АИС-БУ

1.2.4.

Вопросы для самоконтроля

2.

Раздел 2. Организация и технология функционирования автоматизированных информационных систем бухгалтерского учета

2.1.

Глава 7. Особенности построения и функционирования многопользовательских АИС-БУ

2.1.1.

Основные принципы построения многопользовательских АИС-БУ

2.1.2.

Технологии многопользовательской работы в АИС-БУ

2.1.3.

Организация информационной базы многопользовательских АИС-БУ

2.1.4.

Вопросы для самоконтроля

2.2.

Глава 8. Зарубежные системы автоматизации бухгалтерского учета

2.2.1.

Краткая характеристика зарубежных программных средств автоматизации учета

2.2.2.

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

2.2.3.

Автоматизация параллельного ведения учета в нескольких стандартах

2.2.4.

Вопросы для самоконтроля

3.

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

3.1.

Глава 10. Создание и ввод в эксплуатацию АИС-БУ

3.1.1.

Подходы к созданию и внедрению АИС-БУ

3.1.2.

Критерии выбора программного обеспечения АИС-БУ

3.1.3.

Адаптация тиражных программ при создании АИС-БУ

3.1.4.

Ввод АИС-БУ в эксплуатацию

3.1.5.

Вопросы для самоконтроля

3.2.

Глава 11. Эксплуатация и сопровождение АИС-БУ

3.2.1.

Правовая поддержка АИС-БУ

3.2.2.

Методическое сопровождение АИС-БУ

3.2.3.

Обновление программного обеспечения АИС-БУ

3.2.4.

Вопросы для самоконтроля

4.

Раздел 4. Автоматизированные информационные системы анализа и аудита

4.1.

Глава 12. Автоматизированные информационные системы экономического анализа

4.1.1.

Системы автоматизации финансового анализа

4.1.2.

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

4.1.3.

Системы автоматизации анализа инвестиционных проектов

4.1.4.

Вопросы для самоконтроля

4.2.

Глава 13. Автоматизированные информационные системы аудита

4.2.1.

Особенности проведения аудита в среде АИС

4.2.2.

Программное обеспечение АИС-аудита

4.2.3.

Вопросы для самоконтроля

5.

Литература

Указатели
15   указатель иллюстраций
Рис. 3.1. Схема разделения функций обработки и доступа к данным в АИС-БУ, построенной на архитектуре «файл-сервер» Рис. 3.2. Схема взаимодействия клиентского и серверного программного обеспечения при использовании модели «толстого» клиента Рис. 3.3. Схема функционирования ПО АСБУ при использовании модели «тонкого» клиента

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

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

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

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

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

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

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

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

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

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

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

    1) локальное функционирование рабочих мест;

    2) обработка информации на основе технологии файл-сервер;

    3) обработка информации на основе технологии клиент-сервер;

    4) полностью централизованная обработка данных.

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

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

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

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

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

При создании сетей для небольших рабочих групп часто используются так называемые одноранговые сети. В них все компьютеры считаются равноправными. Данные могут быть разнесены по отдельным рабочим местам, но при необходимости они могут быть оперативно востребованы с других компьютеров, если их пользователям разрешен доступ к ним. Чтобы данные компьютера были доступны другим пользователям сети, он должен быть включен и подсоединен к сети с помощью специального программного обеспечения. В настоящий момент одноранговые сети обычно базируются на использовании Windows'95, Windows'98 или Windows Pro 2000. Для небольшой бухгалтерии (3-5 чел.) такое решение вполне приемлемо. Однако при численности сотрудников более 5-7 нередко начинают возникать проблемы, связанные с недостаточной производительностью системы. Они вызваны тем, что часть вычислительных ресурсов каждый компьютер сети тратит на обслуживание процесса пересылки данных, хранимых в нем и запрашиваемых с других компьютеров.

Поэтому при большем числе рабочих мест применяются так называемые сети с выделенным сервером - компьютером, выполняющим функции обслуживания сети. В этом случае общие для всех пользователей данные обычно хранятся именно на сетевом сервере. На сетевых серверах устанавливается специальное программное обеспечение - так называемые сетевые операционные системы. Обычно это Novell Netware, Windows NT Server, Windows Server 2000, реже OS/2 или различные разновидности UNIX. Сетевые операционные системы специально оптимизированы для обслуживания групповой работы большого числа пользователей с данными общего пользования, размещенными на сервере, а также с высокопроизводительным периферийным оборудованием, доступным всем пользователям сети (принтерами, модемами и т.д.). На рабочих же местах могут использоваться привычные для большинства пользователей системы: DOS и Windows.

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

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

Рис. 3.1. Схема разделения функций обработки и доступа к данным в АИС-БУ, построенной на архитектуре «файл-сервер»

Рис. 3.1. Схема разделения функций обработки и доступа к данным в АИС-БУ, построенной на архитектуре «файл-сервер»

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

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

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

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

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

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

Модель «толстого» клиента. В настоящее время большинство отечественных бухгалтерских программ, основанных на технологии клиент-сервер, используют так называемую модель «толстого» клиента (рис. 3.2).

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

Рис. 3.2. Схема взаимодействия клиентского и серверного программного обеспечения при использовании модели «толстого» клиента

Рис. 3.2. Схема взаимодействия клиентского и серверного программного обеспечения при использовании модели «толстого» клиента

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

Возникает вопрос: почему для выполнения столь простых вычислений надо передавать записи по сети, а не выполнять их непосредственно на сервере? Здесь есть немало причин. Основной из них является то, что построение системы на основе модели «толстого» клиента более простое с точки зрения технической реализации. Большинство систем, построенных по этому принципу, изначально выросли из программ, построенных в архитектуре файл-сервер путем использования специальных системных средств, применение которых не требует значительной переработки программ, которая необходима при выполнении разделения функций прикладных вычислений между клиентом и сервером. Возможность применения этих специальных средств обусловлена тем, что функции доступа к данным могут быть в значительной степени стандартизованы благодаря использованию СУБД, на основе которых создается большинство бухгалтерских программ.

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

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

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

Рис. 3.3. Схема функционирования ПО АСБУ при использовании модели «тонкого» клиента

Рис. 3.3. Схема функционирования ПО АСБУ при использовании модели «тонкого» клиента

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

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

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

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

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

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

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

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

Рассмотренный способ построения системы обработки данных можно реализовать, например, при использовании на сервере специального программного обеспечения Windows NT Terminal Server Edition (сокращенное название - Hydra). Например, многие партнеры фирмы «1С» довольно широко применяют этот программный продукт при развертывании систем обработки данных, основанных на применении программ системы «1С:Предприятие» у своих клиентов. Это, по их оценке, нередко позволяет существенно сократить сроки внедрения автоматизированной системы и совокупные расходы клиентов на модификацию средств вычислительной техники. За счет применения Hydra даже при комплектовании рабочих мест компьютерами на базе процессоров Intel 80386, 80486 можно достичь возможности выполнять все самые современные приложения Windows, требующие значительных технических ресурсов. Модель полностью централизованной обработки оказывается очень эффективной при применении в качестве сетевой операционной системы той или иной разновидности Unix. В частности, уже довольно часто в качестве сетевой ОС применяют свободно распространяемую (бесплатную) операционную систему Linux, обеспечивающую чрезвычайно высокую производительность при одновременном обслуживании большого числа пользователей. При этом совершенно необязательно, чтобы прикладная программа была написана специально для этой операционной системы, поскольку Linux имеет эмулятор DOS, позволяющий выполнять большинство программ, написанных для DOS.

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

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

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

Можно выделить три основные модели организации информационной базы в многопользовательских системах:

    1) распределенных данных;

    2) централизованных справочников;

    3) полностью централизованных данных.

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

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

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

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

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

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

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

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

Модель централизованных справочников была реализована в системах «Бухучет-Финансы-Бизнес» фирмы «Инфософт», ранних версиях разработок фирмы «Электронные деньги» и некоторых других системах.

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

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

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

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

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

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

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

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

Примером реализации подхода, основанного на групповой контировке однотипных документов, является система «1С:Торговля». Здесь документы по торговым операциям сразу в бухгалтерском учете не проводятся, но в конце месяца запускается специальная технологическая процедура, в результате выполнения которой соответствующая информация сводится, и по ней формируются проводки. В качестве другого примера можно сослаться на систему «Галактика», где изначально заложено разделение данных оперативного и бухгалтерского учета, которые могут существовать порознь друг от друга. Здесь для большинства хозяйственных операций проводки могут формироваться сразу по пачкам однотипных документов в свернутом, агрегированном виде.

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

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

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

1. Что понимают под многопользовательскими АИС-БУ? Какие бывают многопользовательские системы автоматизации бухгалтерского учета?

2. Определите основные особенности организации информационной базы в многопользовательских АИС-БУ.

3. Какова роль администратора в комплексных системах автоматизации бухгалтерского учета?

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

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

6. Как организована обработка данных при технологии «файл-сервер». Отметьте достоинства и недостатки этой технологии.

7. Как организована обработка данных при технологии «клиент-сервер». Отметьте достоинства и недостатки этой технологии.

8. Какие программные компоненты необходимы для функционирования технологии «клиент-сервер» и их назначение?

9. Охарактеризуйте технологию полностью централизованной I обработки.

10. Приведите различия организации информационной базы в внесетевых и сетевых многопользовательских АИС-БУ.

11. Назовите модели организации информационной базы в многопользовательских АИС-БУ.

12. Охарактеризуйте модель распределенных данных, отметьте ее достоинства и недостатки. Приведите примеры реализации.

13. Какие проблемы появляются при интеграции децентрализованных баз данных и как они решаются?

14. Характеризуйте модель централизованных справочников, отметьте ее достоинства и недостатки. Приведите примеры реализации.

15. Охарактеризуйте модель полностью централизованных данных, отметьте ее достоинства и недостатки. Приведите примеры реализации.

16. Какие факторы учитываются при выборе модели организации информационной базы в многопользовательских АИС-БУ?

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

Наиболее мощными, известными и распространенными во всем мире являются комплексные системы автоматизации управления, разработанные фирмами SAP AG, Oracle, Baan, J.D.Ed-vards, People Soft. Кроме них на рынке стран СНГ продвигается еще около 20 пакетов программ менее известных западных производителей.

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

    1) комплексность подхода к решению задач автоматизации управления;

    2) соответствие современным западным стандартам управления и учета;

    3) высокий уровень масштабируемости;

    4) модульность;

    5) интернациональность;

    6) полномасштабное использование возможностей современных информационных технологий.

В реализации этих принципов и состоит основное достоинство этих систем.

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

Соответствие современным западным стандартам управления и учета. Комплексные системы автоматизации управления поддерживают все важнейшие стандарты, принятые при управлении западными предприятиями (ERP, CSRP и т.д.). Поэтому часто их даже называют ERP-системами. Они позволяют организовать учет и проводить анализ в соответствии с международными стандартами (GAAP, IAS). Именно это обстоятельство часто является основной причиной при выборе системы на предприятиях с иностранным участием. Отечественные же разработки в большинстве своем пока не обеспечивают полномасштабной поддержки западных стандартов управления, хотя поддержка международных стандартов учета некоторыми из них уже обеспечивается.

Высокий уровень масштабируемости. Наиболее мощные и функционально-полные западные системы автоматизации управления являются многоплатформенными, то есть могут использоваться практически на всех программно-аппаратных платформах ведущих мировых производителей. Это означает, что они могут функционировать практически на всех распространенных типах ЭВМ под управлением самых разных операционных систем, а не только на персональных компьютерах. Российские же разработки обычно могут выполняться только на персональных ЭВМ, использующих процесоры фирмы Intel или совместимые с ними, под управлением операционных систем DOS или Windows. Кроме того, западные системы могут использоваться совместно с СУБД всех ведущих производителей - Oracle, MS SQL-server, Informix, Sybase, DB/2 и т.д. Большинство же отечественных разработок создаются для использования совместно с одной-двумя СУБД.

За счет многоплатформенности западные системы автоматизации управления могут применяться как на относительно небольших предприятиях, так и в гигантских корпорациях, где число одновременно работающих с системой пользователей может достигать нескольких тысяч человек, а размеры баз данных исчисляться сотнями гигабайт или даже терабайтами. В больших структурах для управления сетями компьютеров приходится использовать Тошные мини-ЭВМ типа AS/400 или RS/6000, а нередко и мэйнфреймы. Наиболее же крупные известные внедрения российских разработок пока развертываются в информационных системах, насчитывающих не более 200-300 пользователей.

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

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

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

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

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

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

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

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

Создание АИС-БУ на основе многих западных программных продуктов сдерживается существенными системными различиями в методологии ведения бухгалтерского учета в России и западных странах. Эти различия находят непосредственное отражение в программных средствах российских и западных разработчиков. Рассмотрим основные из них.

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

{Дебетуемый счет} {Кредитуемый счет} {Сумма}

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

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

{Тип оборота: дебет или кредит} {Счет} {Сумма}

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

Д) {Дебетуемый счет } {Сумма}

К) {Кредитуемый счет} {Сумма}

Где «Д» - признак оборота по дебету, а «К» - признак оборота по кредиту.

Форма представления строк проводок с односторонней записью в программах может быть различной. Может использоваться структура записи, приведенная выше, с явным выделением типа оборота. Может применяться двухколоночный способ записи суммы: одна колонка для сумм, относимых в дебет, а другая - для сумм, относимых в кредит. В этом случае признак типа оборота уже не нужен, поскольку он определяется явным образом. Иногда, как, например, в программном комплексе Scala, используется и такой прием, при котором суммы, относимые в дебет счета, записываются со знаком «плюс», а суммы, относимые в кредит - со знаком «минус».

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

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

Untitled Document

Дебет
Кредит
Сумма
62
46
1200
46
68
200

В результате возникают следующие величины оборотов счетов:

Untitled Document

Счет
Дебет
Кредит
62
1200
 
46
200
1200
68
 
200

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

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

Untitled Document

Счет
Дебет
Кредит
62
1200
 
46
 
1200
46
 200
 
68
 
200

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

Untitled Document

Счет
Дебет
Кредит
62
1200
 
46
 
1000
68
 
200

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

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

Таким образом, использование односторонней записи в западном учете логически приводит к тому, что здесь используется оборот-нетто. Это прямым образом сказывается и на системах автоматизации, многие из которых автоматически вычисляют оборот-нетто по вводимым пользователем записям на счетах. Для многих западных систем автоматизации учета (IDEAS, Scala, platinum/DOS и др.) проблема получения оборота-брутто является трудно разрешимой и часто требует использования искусственных приемов формирования записей на счетах, увеличивая трудоемкость ручного ввода данных.

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

В качестве примера рассмотрим порядок отражения на счетах операции реализации основных средств.

При использовании двусторонних проводок будут сделаны следующие записи (цифры условные):

Untitled Document

Дебет
Кредит
Сумма
62
47
1200
47
68
200
47
01
800
02
47
400

В западных системах автоматизации, основываясь на принципе оборота-нетто и отражения кредитовых оборотов со знаком «минус», будут зафиксированы следующие записи:

Untitled Document

Счет
Сумма
62
+ 1200
47
- 600
68
- 200
01
- 800
02
+ 400

Здесь одновременно и дебетуется и кредитуется несколько счетов. Прямая связь между различными счетами разорвана. Поэтому ответить на вопрос, каков был суммарный оборот с кредита счета X в дебет счета Y, не представляется возможным. Следовательно, не может идти речи и о получении таких типичных для российской практики учета регистров, как журналы-ордера и дебетовые ведомости. То же касается и Главной книги, под которой в западном учете понимается нечто иное, чем в российском.

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

Учет взаиморасчетов и развернутое сальдо. В зарубежной практике не применяются активно-пассивные счета. Для учета расчетных операций отдельно используются активные счета «К получению» и пассивные счета «К оплате». Например, в США при продаже товаров сумма оплаты относится в кредит счета «Выручка от продаж» и в дебет счета «Наличность» (при продаже за наличные) или счета «К получению» (при продаже в кредит), относящегося к счетам дебиторов. Учет расчетов по этому счету ведется в специальном регистре, именуемом «Журнал продаж». При поступлении денежных средств дебиторская задолженность по данному покупателю гасится. Если покупатель сделал предоплату, то соответствующая сумма отражается на другом счете в другом журнале.

Это в значительной степени похоже на использование пары счетов 62 «Расчеты с покупателями» и 64 «Расчеты по авансам полученным» в российском учете. При их использовании строго по назначению первый всегда является активным, а второй - пассивным. При расчетах с поставщиками такими счетами являются счета 60 «Расчеты с поставщиками и подрядчиками» и 61 «Расчеты по авансам выданным». Здесь первый является пассивным, а второй - активным.

Однако в России распространена практика, когда расчеты отражаются на одном счете, например, при расчетах с поставщиками используется только счет 60 «Расчеты с поставщиками и подрядчиками». В этом случае при расчетах с одними поставщиками может иметь место дебиторская, а с другими - кредиторская задолженности. Их сведение недопустимо, и потому счет должен иметь двустороннее, развернутое сальдо, отражающее как дебиторскую, так и кредиторскую задолженности. Особенно типична эта ситуация при отражении операций взаиморасчетов на счете 76 «Расчеты с разными дебиторами и кредиторами».

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

В последнем случае при использовании счета 76 «Расчеты с разными дебиторами и кредиторами» одним из решений является использование разных субсчетов для отражения дебетовых и кредитовых оборотов по каждому контрагенту и последующего «сведения» их опять-таки по каждому из них. При таком подходе для уменьшения объема ручной работы целесообразно использовать механизм типовых операций, позволяющий автоматизировать выполнение расчетов и формирование «сводящих» операций. К сожалению, во многих западных программах возможности настройки правил автоматизации процедур формирования записей на счетах весьма ограничены. Нередко (как, например, в системе Platinum/DOS) для этого требуется разработка специальных программ, не являющихся полностью интегрированными с основной системой. Для их использования приходится «выгружать» необходимую информацию из базы данных основной программы, выполнять ее обработку вспомогательной программой, а потом заново, уже в измененном виде, опять загружать в базу данных. Очевидно, что это не очень технологично.

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

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

Здесь по кредиту счета 46 отражается сумма 1200. Предположим, что далее возникает нештатная ситуация, когда отчетность уже сформирована и сдана, но требуется отменить ранее проведенную операцию. Во многих западных системах это потребует формирования «зеркально» отраженных проводок, в которых дебет заменяется на кредит, и наоборот. В результате по счету 46 будет получен кредитовый оборот на сумму 1200 и дебетовый оборот на ту же сумму. Остаток нулевой, но оборот по этой операции ненулевой. Для западного учета это не имеет значения, поскольку используется оборот-нетто. А для российского учета величина оборота важна, хотя бы потому, что некоторые налоги исчисляются от базы, зависящей от оборота конкретных счетов. Поэтому и требуется операция сторнирования, а не «обратной» записи. Для многих западных систем автоматизации бухгалтерского учета (IDEAS, Platinum/DOS, SunSystems и т.д.) проблема формирования сторнирующих записей трудно разрешима.

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

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

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

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

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

Например, в начале 1998 г. основное средство стоимостью 1000$ было передано российской стороне иностранным партнером. При курсе 6 руб. за 1$ его стоимость составляла 6000 руб. По этой сумме оно и было поставлено на баланс. Если поделить его балансовую стоимость по состоянию на апрель 1999 года, то при курсе 25 руб. за 1$ окажется, что его стоимость составляет всего 240$. Но ведь понятно, что с точки зрения иностранного партнера стоимость основного средства не могла снизиться за год на такую величину.

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

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

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

Первый способ предполагает детальную проработку системы субсчетов и разрезов аналитики для обеспечения возможности расчета на основе их сальдо и оборотов всех показателей, входящих в отчетность, предоставляемую иностранному партнеру. Это может потребовать существенной детализации системы субсчетов и аналитических счетов. В российских разработках такой подход впервые был применен в разработках фирмы «Монолит-Инфо». При использовании программ, позволяющих вести только один план счетов, например, стандартной версии «1С: Бухгалтерии 7.7», этот путь является единственно возможным.

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

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

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

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

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

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

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

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

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

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

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

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

© Центр дистанционного образования МГУП