Совместно используемое хранилище данных о сделках (Shared Transaction Repository, STR)

Таблица STR пытается определить минимум важнейших данных для осуществляемых сделок. Она хранит "черновики" сделок ("предложения"), которые переданы отправителем и могут быть одобрены адресатом (далее - "получатель" или "другая сторона").

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

STR - компонент инфраструктуры, который можно реализовать как:

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

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

Если получатель согласен с предложенными условиями, он заполняет или подписывает остающиеся поля строки и пересылает партнеру. Это можно делать через HTML-интерфейс на сервере STR или при помощи обмена документами XML.

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

Вы спросите: "Если все содержание можно вложить в файл XML, зачем тогда столько колонок?" Цель здесь - обеспечить минимальный набор индексов, чтобы STR мог отвечать на запросы без синтаксического разбора файлов XML. При разработке было принято решение перенести Код счета, Сумму и Валюту в отдельные поля, чтобы можно было делать запросы по этим параметрам. Такие данные - основание для отчетов по срочным счетам к оплате/получению, по остатку кассы и т. д. Они автоматически сверяются с записями деловых партнеров. Функция STR - учет между компаниями.

STR может фиксировать все виды элементарных коммерческих сделок, вводя поля данных XML в каждую строку базы данных. Эти поля содержат коммерческие документы (например, счет-фактуру или платежные поручения, используемые местными системами пользователей STR или торговыми партнерами). Существует 10 полей, совместно используемых двумя сторонами, и по 7 закрытых полей для каждой из сторон. (Это учет с единой записью, где одна строка представляет одну сделку между двумя сторонами. Таблица STR балансов не сводит).

Требования к любому клиентскому приложению таковы:

• Инициировать сделки, формируя сложный документ, который содержит: дату сделки, идентификационные коды и URL обеих сторон, сумму сделки и, по желанию, иные данные, такие как условия компенсации денежных средств и т. д. Инициатор может использовать в сообщении цифровую подпись. Сообщение посылается многосторонней электронной почтой MIME или объявлением HTTP, которые выходят за рамки данной спецификации. Настоящая спецификация (STR ver. 0.60) предполагает наличие средств связи для передачи сделки на сервер STR;
• Принимать сделки от других участников. Получатель добавляет к документу о сделке одно дополнительное значение - код-идентификатор пользователя. Прежде чем передать на STR заполненный документ, пользователь может, по желанию, поставить в нем свою подпись.

Чтобы проиллюстрировать работу STR, рассмотрим в качестве его составной части простую веб-книгу. Это Главная книга с двойной записью, которая ведется в Интернете, через браузер, и имеет дополнительную функцию отправления и получения сделок STR. (Веб-книги - это серверные приложения, с точки зрения провайдеров бизнес-услуг они являются клиентами).

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

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

В дополнение к исходным полям базы данных, документы произвольной сложности (счет-фактура, заказ, отчет о движении материальных активов, данные о зарплате и т. д.) хранятся в документе XML сплошным текстом в одном поле. Пользователи могут, при желании, включать в полезные поля STR сообщения xCBL или основные компоненты EDI или ebXML. Однако сама веб-книга как клиент не будет функциональной без Главного журнала учета.

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

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

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

Пользователи, как правило, будут хранить детали своих сделок на серверах ASP или BSP. В таких случаях им понадобится доступ сверху вниз: от их корневой книги к таким деталям.

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

Продолжение в следующем выпуске.