STR: Приложение для бухгалтера

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

Обратите внимание, что в сетевом (network-centric) учете:

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

На минуту прервемся, и пусть нам возразят владельцы малых предприятий:

• Цель этой архитектуры - по возможности упростить совместное отражение сделок, убрав лишние данные и риск несоответствия между записями партнеров.
• Да ну! И я должен мою Главную книгу хранить на вашем компьютере, в Интернете?!
• Нет. Вы будете хранить только дату, сумму и описание событий ваших сделок в зашифрованном виде, чтобы читать их могли только вы и ваш партнер.
• Смешно! Зачем мне делиться данными с клиентами или поставщиками?
• А вы и так ими делитесь. Храниться будет как бы моментальный снимок того, что вы купили, продали, согласовали. Ваш клиент или поставщик уже хранит именно эту информацию, но у себя. То о чем вы договорились, и есть та самая информация.

Рассмотрим варианты. Совместное хранилище данных о сделках можно получить, используя любую мощную систему учета для нескольких компаний. Такая Главная книга для каждого участника позволяет вести классическую двойную бухгалтерию (CDEA). Рассмотрим пример, в котором Филиал А оплачивает затраты Филиала В посредством "межфирменного счета" ("the intercompany account").

Это классический межфирменный учет - так можно делать и сегодня. Установите любой крупный пакет ПО средней мощности с интерфейсом браузера типа Great Plains или Lawson. Продайте подписку ряду компаний. Создайте бизнес-объекты, чтобы заносить в соответствующую книгу каждое событие сделок между компаниями-подписчиками. Средства к оплате или получению между фирмами всегда будут сверены, если оба участника сделки - ваши абоненты. Возможно, некоторые компании, нуждающиеся в сильной интеграции, подпишутся на ваши услуги как, скажем, участника цепи снабжения.

Однако книги CDEA для нескольких компаний не работают, потому что:

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

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

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

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

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

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

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