CustIS Accounting — передовая технология автоматизации учета и анализа финансово-хозяйственной деятельности

Рахтеенко В. Е., Хомюк С. В., Цепков М. А.

Статья рассказывает историю создания ядра CustIS Acconting и распределенной АБС на его основе для ЛипецкКомБанка (ЛКБ) примерно за полгода в 1997 году. Работы вызваны изменением с 01.01.1998 банковского плана счетов бухгалтерского учета и ЛКБ принял решение заказать новую систему CUSTIS. Работы начались летом 1997 года, а 1 января система была запущена в боевую эксплуатацию на серверах всех филиалах банка с репликациями метаданных и документов.
Статья опубликована в журнале «Компьютер в бухгалтерском учете и аудите» 2-1998.

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

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

«Ну хорошо», — говорите Вы, — «а как обстоит дело с предметной частью? Какая именно система лучше всего удовлетворяет именно мои потребности?». Ответ на этот вопрос, возможно, также вызовет Ваше недоумение — с первого взгляда буквально во всех системах есть все, что Вам нужно и даже больше того, что нужно.

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

Тяжела задача авторов этой статьи — надо Вас как-то убедить, что предлагаемая система CustIS Accounting (действительно одна из многих-многих), решает конкретный класс задач лучше, чем кто-либо другой. Исходя из этого, определим вначале такие задачи, а потом (куда деваться!) — начнем по косточкам разбирать, какими характеристиками должна обладать система, чтобы такие задачи решать хорошо, и как эти характеристики реализованы в CustIS Accounting.

Зная на своем опыте, как тяжело вникать в объемные теоретические построения, мы решили построить изложение материала на живом примере.

Кроме этого, последняя треть статьи посвящена изложению примера реализации в CustIS Accounting конкретного документа.

Живой пример

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

Предыстория

Наша компания в течение последних 3-х лет занималась разработкой заказных систем автоматизации и учета для торговых компаний и банков. Характерная черта этих разработок — большое разнообразие предметных областей: от управленческого учета и многоуровневого маркетинга в торговых компаниях до автоматизации торгов ГКО/ОФЗ и отделов дилинга в банках.

Постепенно стала возникать концепция «общей схемы автоматизации» и инструментария, который эффективно ее строит. К середине 1997 года у нас была готова (изложена на бумаге) концепция таких «общих систем автоматизации» и техническое задание на CustIS Accounting — соответствующего инструментального средства. Фактически CustIS Accounting — это универсальное ядро произвольной системы автоматизации, которое потом «обрастает» конкретным содержанием. Заметим сразу, что CustIS Accounting предоставляет средства для всего спектра потребностей систем автоматизации: документооборота, бухгалтерии и произвольных учетных систем и аналитических отчетов по ним.

История

В середине того же 1997 года наша компания получает заказ на автоматизацию банка. Характерные черты разработки:

Банк имеет семь удаленных филиалов (общая удаленность около 600 км, качество связи от «удовлетворительного» до «плохого», а временами и «совершенно неудовлетворительного»).
Новая автоматизированная система будет установлена во всех подразделениях и должна полностью заменить системы, эксплуатирующиеся до нее.
Полностью автоматизируется работа платежной системы банка: операционного отдела, касс, отдела корр. отношений и т. д.
Частично автоматизируется работа следующих отделов банка: дилинга, валютного, кредитного и депозитного.
Автоматизируется получение необходимой отчетности в объеме требований ЦБ по новому плану счетов.
Система должна быть спроектирована с учетом жестких требований к информационной безопасности, предъявляемых в банковском деле.
Система устанавливается на географически удаленных серверах и должна иметь средства автоматического сбора данных (например, для консолидированной отчетности), а также трансляции изменений/дополнений в существующую бизнес-логику с каждого сервера на все остальные.
Система должна вступить в эксплуатацию в начале января 1998.

По ряду причин собственно разработка стартовала в начале августа 1997. Итак, «на все про все», как говорится, отводилось ровно 5 месяцев.

Огласим принятые тогда решения, полученные результаты и, быть может, самое интересное — сроки.

Решения

Учитывая сжатые сроки разработки, было решено реализовать CustIS Accounting — инструмент для эффективного наполнения системы содержанием. В частности, CustIS Accounting должен был предоставить декларативные объектно-ориентированные средства описания предметной области.

Разработка системы на CustIS Accounting преследовала, кроме прочего, еще одну цель — расширить коллектив разработчиков экспертами со стороны заказчика. Как показало дальнейшее, это было правильное и, возможно, единственно верное решение.

Сроки

Огласим повременную раскладку разработки:

3.5 месяца (август- начало ноября) — разработка конструктора CustIS Accounting.
2 месяца (ноябрь-декабрь) — настройка конкретной реализации, то есть наполнение ядра CustIS Accounting содержательной частью банковской системы.

Результаты и технические характеристики системы

На данный момент система эксплуатируется в головном банке и во всех его подразделениях.

Технические характеристики системы
Система управления базой данных (СУБД)	ORACLE V7.3.3
Число удаленных серверов БД	7
Число конкурентных рабочих мест на каждом сервере	От 50 до 100
Механизм межсерверного обмена данными	Репликации ORACLE
Наибольшее расстояние между серверами БД, осуществляющими репликации	Около 600 км
Операционные системы на серверах БД	SCO UNIX ENTERPRISE V5.0.2, Windows NT 4.0
Операционные системы на клиентских местах	Windows 95, Windows NT 4.0, SCO UNIX

В системе реализовано:

Около 80 типов документов, среди них — 30 типов отчетов, 150 типов агрегатов (объектов — не являющихся документами).
Около 10 ролей (различных прав доступа).
Пользовательский интерфейс насчитывает около 250 экранных форм. Агрегаты и документы редко используемых типов редактируются через единый «администраторский» интерфейс Ядра CustIS Accounting.

Характеристики идеальной системы

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

Итак, идеальная система автоматизации должна, на наш взгляд, обладать следующими характеристиками:

Обеспечивать быстрый одновременный доступ (OLTP^[1]) к актуальным данным нескольких сот пользователей.
Предоставлять ведение разнопланового учета (учета в разных планах счетов) с максимально интересующей подробностью.
Обеспечивать оперативный контроль за текущими состояниями. Например — остатки по счетам, состояния складов, обязательств и т.д.
Обладать свойством адаптивности, то есть схема учета должна быть достаточно гибкой, чтобы изменение правил учета можно было производить на «живой» системе. В идеале изменение бизнес-логики должно производиться конечным пользователем с правами администратора прикладной части системы (экспертом-прикладником).
Система должна обеспечивать произвольную отчетность по накопленной информации.
Система должна обладать информационной надежностью и безопасностью, на том уровне, который обеспечивают регулярные средства наиболее мощных и современных СУБД.
Иметь хорошую интеграцию с другими системами:
возможность on-line проектирования отчетности сторонними системами отчето-генерации;
возможность импорта и экспорта данных, в том числе в многомерные базы данных (OLAP);
возможность разработки сторонних on-line приложений;
Обладать прозрачностью, то есть каждый пользователь системы работает:

в понятных ему терминах;
в рамках предоставленных ему возможностей;
на множестве открытых для него данных;

Поддерживать фискальность и версионность, то есть всякое изменение информации в системе авторизовано, и ведется история версий информации.
Возможность одновременного активного редактирования данных и подготовки массивной отчетности (DSS^[2]). То есть OLTP+DSS.
В системе должна быть обеспечена возможность географической распределенности базы данных с достаточно оперативной связью между серверами.

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

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

Класс задач, решаемых CustIS Accounting

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

Для ответа на этот вопрос мы предлагаем заполнить приводящуюся ниже анкету^[3].

OLTP. Сколько конкурентных пользователей предполагается на сервер? От 1 до 10 = 0 баллов, 10‑100 = 50 баллов, 100‑1000 = 200 баллов
Адаптивность. Очень хорошая = 150, хорошая = 50, средняя = 10, не нужна = 0 баллов
Разноплановый учет. Любое число планов учета = 100, Фиксированное = 40, не нужно = 0 баллов
Оперативный контроль. Расширяемый = 100, Фиксированный = 40, Не нужен = 0 баллов
В существующих системах прикладная часть устраивает: полностью (99‑100 %) = 0 баллов, в основном (~90 %) = 5 баллов, отсутствует несколько важных разделов(~80 %) = 10 баллов, похожа на то, что Вам нужно, но только в общих чертах (~50 %) = 100 баллов, ничего похожего на рынке не обнаружено (0 %) = 500 баллов
Отчетность. Произвольная = 100, Фиксированная нестандартная = 50, фиксированная стандартная = 0 баллов
Информационная надежность. Очень хорошая = 50, хорошая = 15, средняя = 5 баллов
Информационная безопасность необходима: Жесткая = 100 баллов, Мягкая = 20 баллов, не нужна = 0 баллов
Географическая распределенность. Нужна = 150, не нужна = 0 баллов
Система обязана поддерживать: фискальность, версионность, прозрачность. Каждый пункт по 20 баллов.
Итого:

Ваши результаты.

Вы набрали	Наши комментарии
Меньше 70	Скорее всего Вам нужна «коробочная» дешевая программа. Ваше счастье — проблемы серьезной автоматизации пока не Ваши проблемы.
От 70 до 200	Скорее всего Вам удастся купить дорогую «коробочную» программу. На некоторое время она должна Вас устроить.
От 200 до 350	Если Вы наберетесь терпения, и правильно выберете фирму контрагента, то Вы можете получить доработанную под Вас дорогую «коробочную» программу. Однако это уже тот вариант, когда деньги, потраченные на полный цикл внедрения программы могут оказаться выше расценок на заказную разработку (например, наших). И если Вы выберете не ту «коробку» — мужайтесь.
От 350 до 700	Вы наш клиент. Задач подобных этой у нас реализовано около 10. Ориентировочный срок реализации — 3‑9 месяцев.
От 700 до 1200	Это уже серьезная задача. Мы имеем опыт разработки таких систем и готовы взяться за ее реализацию. Набрав столько баллов, Вы не можете недооценивать всю серьезность разработки систем такого масштаба. Рискнем даже предположить, что у Вас есть свой немаленький отдел автоматизации, и проблемы автоматизации знакомы Вам не понаслышке. Главный наш козырь — это уже работающие системы «на 1000—1200 баллов», и здравствующие клиенты, у которых можно узнать подробности разработки и внедрения задач такого размера. Задачи такого рода всегда разрабатываются поэтапно. Отметим лишь одно — у нас не бывает этапов длиной более, чем полгода без конкретного результата (не на бумаге, а на экранах мониторов).
Более 1200	Приходите, посмотрим, что можно сделать…

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

Принципы построения CustIS Accounting

Перечислив характеристики «идеальной системы», и попытавшись заранее определить спектр решаемых CustIS Accounting задач c помощью анкеты, перейдем к определению принципов построения нашей системы.

CustIS Accounting является обобщением накопленного нами опыта разработки заказных систем. Схематично строение CustIS Accounting представлено на Рис. 1.

Рис. 1

Далее мы предлагаем поэтапный разбор того, как в CustIS Accounting воплощается каждая характеристика описанной выше «идеальной системы» и как все это связано с Рис. 1.

OLTP, информационная надежность

Информационную надежность необходимо рассматривать в двух аспектах:

Надежность выбранной СУБД как хранилища данных.
Надежность проектных решений (данный аспект надежности во многом определяется выбранным решением проблемы адаптивности).

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

С точки зрения надежности серверной части системы, то есть качества проектирования схем БД — таблиц, представлений (view), триггеров, процедур, функций, пакетов, последовательностей и связей между ними.
С точки зрения способа взаимодействия клиентской и серверной частей системы («толстый» или «тонкий» клиент).
С точки зрения надежности клиентской части приложения.

Очевидно, что система, которая спроектирована с повышенными требованиями к надежности, по производительности уступает системам, не уделяющим этому аспекту достаточного внимания. Единственное, что в этом случае спасает разработчика — это то, что и вычислительная техника, и программное обеспечение стали достаточно мощными для решения задачи контроля корректности данных без ущерба для решения задач OLPT. Ведь никого не интересует, какова загруженность процессора — 10 % или 50 %, пока это не начинает сдерживать работу пользователя.

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

Надежная и мощная СУБД — Oracle

Перепробовав в процессе роста компании и решаемых ею задач следующие варианты:

Microsoft Access (строго говоря это даже «БД» назвать нельзя, но работали мы с этим продуктом 4 года назад, потому и упоминаем).
Sybase SQL AnyWhere (бывший Watcom SQL).
Informix.

мы серьезно проанализировали рынок промышленных баз данных (по сути круг претендентов быстро сократился до двух претендентов — Sybase и Oracle) и два года назад выбрали Oracle. Мы не будем с фактами и сравнительными характеристиками в руках убеждать Вас, что сделали верный выбор — это не предмет данной статьи. Мы только констатируем, что после плотного использования разных инструментов Oracle в течение двух лет, ни разу о своем выборе не пожалели. Фактически, нам не дали ни одного серьезного повода.

Если Вы подумали, что мы используем этот инструмент поверхностно, то читайте дальше — Вас ждут: совместное использование нескольких весьма сложных схем, симметрические репликации между двумя «звездочками», оптимизация запросов к БД на уровне прямой работы с планами решения запросов (Hints), и т.д.

Писать на эту тему можно много (тема-то практически безграничная), но приходится ограничиться фразой: «звоните, приходите — все покажем и расскажем».

Надежность проектных решений

На наш взгляд, 80 % процентов успеха проекта определяется качеством разработки серверной части системы. При этом необходимым условием является использование очень тонкого^[4] клиента. Обосновать это можно следующими соображениями:

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

Эти два соображения можно резюмировать так:: «толстый сервер + несколько тонких функционально различных клиентов».

Кроме того, чем лучше проработана серверная часть, тем проще и безопаснее решаются задачи интеграции.

Надежность серверной части системы

Если взглянуть на схему «Принципы построения системы» (Рис. 1) и задаться вопросом, какую часть из нарисованного в CustIS Accounting выполняет серверная часть, то последует любопытный ответ — всю, то есть 100 % функционала реализовано на серверной части. Таким образом, надежность серверной части решающим образом определяет надежность всей системы в целом.

Надежность серверной части в CustIS Accounting достигается следующими подходами:

БД в CustIS Accounting спроектирована так, что ее реляционная структура остается неизменной на протяжении всего цикла жизни системы. Появление новых типов (и, естественно, экземпляров) документов, отчетов, планов счетов, иерархий и т.д. не приводит к изменению структуры БД.
Основной функционал системы (что есть «основной функционал» рассмотрено в пункте «симбиоз декларативного и функционального подхода») также не изменяется. На данный момент этот функционал оттестирован и находится в промышленной эксплуатации нескольких сот пользователей на семи разных серверах.
Целостность данных контролируется средствами БД: ключи (primary and foreign keys), триггеры, индексы, процедуры, функции, пакеты. Это делается по возможности максимально жестко.
Проектирование схемы БД выполнено наиболее квалифицированными специалистами фирмы.

Надежность клиентской части системы

Как уже было сказано, клиентская часть при выбранном нами подходе не оказывает решающего значения на надежность системы. Фактически, в нашем случае серверная часть системы определяет ее надежность, а клиентская обеспечивает «удобность и красивость». Образно говоря, серверная часть — это тело системы (здоровое или больное), а клиентская — одежда для этого тела (модная или нет, практичная или не очень).

Еще одно преимущество избранного подхода в том, что тонкого клиента поменять гораздо проще: не нравится Вам PowerBuilder — напишите интерфейс на чем-нибудь еще: Delphi, Centura Builder, на Access’е наконец — то есть не нравится Вам платье — купите себе юбку и жакет или брючный костюм.

Причины, почему это сделать проще в схеме с тонким клиентом — достаточно очевидны, но, все-таки, кратко укажем на основные:

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

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

Анализ рынка показывает: на данный момент Sybase Power Builder — одно из лучших решений проблемы построения интерфейсов. Почему это не Delphi, Centura Builder или Access — это не предмет рассмотрения данной статьи. Единственное, что здесь стоит сказать, что мы остановились на Sybase Power Builder после многих экспериментов с инструментами различных производителей.

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

OLTP

Следующая характеристика «идеальной системы», подлежащая разбору — это OLTP. Из вышесказанного понятно, что схемы БД, реализующие CustIS Accounting, достаточно сложны. Действительно, чего стоит один только провозглашенный выше тезис о том, что «реляционная структура остается неизменной на протяжении всего цикла жизни системы». Другой пример — реализованные схемы симметрических репликаций.

Но если Вы подумали, что это достигается количественным, а не качественным подходом, то Вы ошиблись. Скажем лишь, что структура БД состоит из менее, чем 100 таблиц (хотя и не на много). Для такой задачи это очень и очень мало. А вот связи между этими таблицами — весьма сложные.

Можно ли при такой сложной структуре БД добиться разумной производительности? Да, можно. Используя именно постоянство структуры БД и представления о том, как будут распределены данные в системе, мы добились того, что все основные части работают с нормальной производительностью. Конечно, для этого пришлось воспользоваться технологиями, предлагаемыми Oracle разработчикам: профилировкой, сбором статистики, ручной оптимизацией запросов к БД (Hints), но это себя оправдало.

Перед тем, как Вы посмотрите на реальную производительность банковской системы, напомним Вам, что правильно спроектированные системы Oracle — ЦПУ-зависимые. То есть, производительность системы определяется процессором, а не периферией. К сожалению, наши серверы в этом смысле весьма «кривые». Профили, которые мы снимали, показывают — у нас еще есть около 250 % резервов, так как ЦПУ используется в пиковой производительности лишь на 40 %. Но и так все неплохо.

Вот данные по производительности.

Производительность реализованной банковской системы

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

Типовой сервер: 1*200MHz Pentium, 256MB RAM, 2*4GB HDD.
Характерный размер БД на одном сервере: 1GB.
Характерный размер таблиц с основной нагрузкой по хранению: от нескольких сот тысяч до нескольких миллионов записей.
Число одновременно работающих пользователей: 30-100 человек.
Число проводимых документов в день: 1000-10000 штук.
Время совершения перехода документа = 0.1-1 сек.
Время ввода документа (естественно, в конкурентной работе) = 1-10 сек^[5].

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

Разноплановый учет

Следующий пункт, объявленный в «характеристиках идеальной системы» — это, как мы его назвали, «разноплановый учет», то есть учет в разных планах счетов. Первый вопрос, который часто задается, такой: «Разноплановый — это сколько плановый? 3^х, 4^х или более?». Ответ прост: сколько Вы этих планов определите, столько их и будет. В нашем примере этих планов семь:

Пять планов для пяти разделов учета банковской бухгалтерии.
План счетов для символов касплана (кассовая отчетность для банков, не фиксируемая в основной бухгалтерии).
«План счетов ОПЕРУ» — план для оперативного учета. В нем происходит учет документов, принятых к исполнению, но еще не проведенные по планам счетов официальной бухгалтерии, то есть еще не «выполненных». «План счетов ОПЕРУ» позволяет оперативно контролировать как собственно «документы в работе», так и ожидаемые изменения остатков на лицевых счетах клиентов одновременно по подразделениям каждого отделения или филиала банка.

Второй вопрос, который естественно вытекает из первого, такой: «Что такое план счетов в терминах CustIS Accounting?».

К сожалению, чтобы ввести точное формальное определение понятия «плана счетов», реализованного в CustIS Accounting, надо излагать достаточно объемные теоретические построения^[6]. Поэтому здесь мы ответим на этот вопрос неформально, попытаемся на разнообразных примерах дать по возможности верное представление.

В терминах рисунка «Принципы построения системы» (Рис. 1) план счетов — это один прямоугольник внутри прямоугольника «Разные системы учета».
Любой учетный регистр, который есть в системе (учетное значение, или, совсем грубо говоря «число, которое вас интересует»), — это значение какого-то счета в каком-то плане счетов. Изменение значений на счетах может производиться только проводками (по правилам двойной записи). Проводки в системе могут появиться только как результат изменения состояния некоторого документа (на схеме «Принципы построения системы» — Рис. 1 — это внутри квадратика «Документооборот»).
Счета, объединенные в один план счетов обладают объединяющими характеристиками (см. Рис. 3):

Множество счетов одного плана счетов замкнуто относительно проводок. То есть не существует проводок между счетами двух разных планов счетов.
Текущие (оперативные) остатки на счетах соответствуют концу некоторой фиксированной даты, которая называется «датой плана счетов», и хранится в атрибутах плана счетов. Изменение этой даты называется «сменой даты плана счетов», и, как правило, делается одним или несколькими переходами этого плана счетов (см. пояснения и Рис. 2).
Над счетами надстраивается произвольное число иерархий. Вообще иерархические структуры используются в CustIS Accounting широко и разнообразно, здесь укажем лишь одно из их применений. Иерархические построения над счетами применяются для следующих целей:

Иерархии задают способы группировки счетов для отчетности, анализа и фиксации (сданные во внешний мир отчетные результаты можно фиксировать — см. «произвольная отчетность»).
Иерархии участвуют в правилах поиска счетов для проводок.
Даты разных планов счетов могут быть разными. Это объясняется тем, что часто один вид учета принципиально «отстает» от другого.

Ну и, наконец, вполне естественно задать вопрос: «Что это значит „Сколько Вы этих планов определите, столько и будет“? Их что, вводит пользователь?». Да, определение в системе нового плана счетов производиться конечным пользователем (не программистом) с правами администратора прикладной части системы, то есть экспертом-прикладником.

С точки зрения системы план счетов — обычный документ. Это заявление, как правило, вызывает удивление: «Ну хорошо, план счетов — это объект, „агрегат“ как вы говорите. Ну документ-то он почему?! Где в нем поля для ввода, где его бумажный аналог?».

Действительно, «бумажного аналога» у плана счетов нет. А документ он потому, что многие действия удобно привязывать к плану счетов и называть это «переходами плана счетов». На Рис. 2 приведена схема переходов документа «Основной план счетов» с краткими пояснениями к действиям, выполняющимся на переходах.

Рис. 2

После того, как Вы ввели новый план счетов, Вы можете:

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

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

Оперативный контроль

Если Вас не нужно убеждать в необходимости оперативного контроля — сразу переходите к следующему абзацу. Для тех же, кто не уверен в необходимости оперативного контроля, или кто просто захочет уточнить, что именно мы под этим термином подразумеваем, продолжим. Оперативный контроль за наиболее важными характеристиками означает, что значения этих характеристик в системе хранятся, а не вычисляются. Все возражения к такому подходу — а мы в свое время видели разработчиков, которые полагали, что «машины считают достаточно быстро» и предполагали, например, текущие остатки по счетам не хранить, а каждый раз вычислять — так вот, эти возражения снимаются при следующем элементарном подсчете. Разделите предполагаемый объем информации на имеющуюся скорость вычислений. Вы получите Очень Большое Число. В нашем примере нормальным является 100—200 тысяч проводок в месяц. Есть счета, по каждому из которых за тот же месяц делается несколько тысяч проводок. Для пересчета остатка по такому счету на нашей технике требуется 1-2 секунды. Это недопустимо медленно для величин, которые нужны постоянно.

В CustIS Accounting оперативно контролируются следующие величины:

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

Адаптивность

Фактически то, как система решает вопрос адаптивности определяет ее долголетие. Возможны следующие варианты:

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

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

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

Рассмотрим экономический аспект проблемы адаптивности. Покупая систему уровня CustIS Accounting, Вы прежде всего заинтересованы в том, чтобы она жила как можно дольше, и сопровождение ее не было очень дорогим. Это связано с тем, что Вы платите большие деньги за покупку системы, потом еще 2-3 раза по столько же за ее внедрение и обучение персонала. Поэтому Вам крайне интересно, чтобы стоимость системы амортизировалась продолжительное время, и во время этой амортизации заметно не росла. Таким образом, можно резюмировать, что вопрос адаптивности является одним из ключевых аспектов окупаемости системы.

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

Симбиоз декларативного и функционального подхода

Суть этого подхода состоит в том, что всякое преобразование информации в системе осуществляется так называемыми «картриджами». Каждый картридж регистрируется в системе определенным образом, реализация его прописывается на языке программирования (PL/SQL) разработчиком, после чего он может использоваться конечным пользователем, то есть экспертом-прикладником. Из повседневной жизни напрашивается аналогия с известным конструктором ЛЕГО, где каждого типа деталей неограниченно много. Строит из него пользователь, а новые детали конструктора по пожеланиям пользователей выпускает разработчик.

Сквозное применение этого метода дает следующие выгоды:

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

Наша практика показала, что даже в тех местах, где введение картриджей казалось поначалу излишеством (дескать, «здесь всегда фиксированный алгоритм, и точка»), их применение оказалось вполне уместным. Картриджи в CustIS Accounting делятся по типам, на данный момент картриджей каждого типа от 10 до 30. Причем картриджи с достаточно общим функционалом прекрасно уживаются с крайне специфичными. Чтобы как-то проиллюстрировать применение картриджей, приведем по несколько картриджей разных типов из нашего примера; первые два будут достаточно общие, а третий — специфический:

Тип картриджей «Для вычисления атрибута агрегата». Атрибуты агрегата (то есть объекта системы) вычисляются по другим атрибутам этого же агрегата. Используются для оперативного хранения производной информации. Примеры:

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

Тип картриджей «Для выполнения действий». Действия в CustIS Accounting выполняются во время совершения документами переходов, иными словами при смене состояний документов. Примеры:

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

Тип картриджей «Для работы с атрибутами агрегата или операции». Примеры:

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

Тип картриджей «Сборка данных для отчетности» (более подробно о них в пункте «Произвольная отчетность»). Примеры:

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

Тип картриджей «Определения счетов проводки по атрибутам операции» . Примеры:

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

Тип картриджей «Вычисления суммы и валюты проводки по атрибутам операции». Примеры:

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

Произвольная отчетность

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

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

Однако, для того, чтобы уметь (пусть и в терминах использования картриджей) описывать, какие именно данные должны попасть в отчетность, в CustIS Accounting разработан формализм описания отчетов, который получил название «обобщенные остатки и обороты по счетам». Ниже кратко описывается этот формализм; кратко потому, что полноценное описание этого механизма — это предмет отдельной статьи.

Счета и балансовые классификаторы

Как мы уже определили, счет — это «учетный регистр» для хранения величин, динамика во времени которых нам интересна для анализа. Единственный способ изменить остаток на счете это совершить проводку, где этот счет стоит «по дебету» или «по кредиту». «Вручную» остатки по счетам в CustIS Accounting изменяться не могут. Так как система помнит всю историю проводок, то фактически она помнит (точнее, всегда может исчислить) — значение остатка по счету, как функцию времени. Обозначим эту функцию как Acc'('t')'.

Самыми примитивными картриджами сбора данных для отчетности, то есть анализа Acc'('t')', являются:

Рассчитать и запомнить остаток по счету такому-то на дату такую-то.
Рассчитать и запомнить оборот по дебету и/или кредиту счета такого-то с даты такой-то по дату такую-то^[7].

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

Балансовый классификатор основного плана счетов задает принятую в банковской бухгалтерии иерархию разделов, подразделов, балансовых счетов 1-ого и 2-ого порядка.
Балансовый классификатор символов касплана.

Привязка между обычными счетами (иногда их называют «лицевыми счетами», чтобы не путать с балансовыми) и балансовыми счетами задается тоже как функция времени Bal_i('Acc', 't'). Количество привязок между конкретным счетом и балансовыми счетами определяется типом счета и задается экспертом-прикладником при описании типа лицевого счета.

Далее вводятся определения:

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

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

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

Рис. 3

Пример создания нового типа отчета

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

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

Атрибутное представление показано на Рис. 4.

Рис. 4

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

Настроечный диалог системы для этого случая показан на Рис. 5.

Рис. 5.

Как видим, в отчет попадут все лицевые счета, которые находятся под балансовыми счетами второго порядка 30301,30302,30109,31302. Заметим, что так как лицевые счета привязаны к балансовым счетам связями, являющимися функциями времени (счет привязан только в тот период, когда он открыт), то средневзвешенные остатки для счета реально будут рассчитаны для периода, являющегося пересечением дат отчета и «времени жизни» счета.

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

Блокировка отчетных результатов

В CustIS Accounting все отчетные данные подразделяются на:

Оперативные, с возможностью блокировки.
Производные, без возможности блокировки.

Оперативные отчетные данные — это данные, которые хранятся в системе в двух экземплярах: как они были посчитаны в отчете (замороженные результаты) и их копия, которая пересчитывается при всякой правке задним числом («незамороженные результаты»). Таким образом, оперативные остатки используются для двух целей:

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

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

On-line отчетность

Система CustIS Accounting реализовала следующий подход к on-line отчетности: от выборок — через оперативные отчетные данные — к остаткам по лицевым счетам в аналитическом плане счетов.

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

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

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

Интеграция

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

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

Разработка сторонних on-line приложений

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

В подтверждение приведем следующие примеры:

В процессе реализации банковской системы, было поставлено требование дублировать некоторую часть интерфейса (20-25 % полного клиентского приложения), на Oracle' 'Forms' 'v'3.0.16'. Это было связано с некоторой специфичностью машинного парка у заказчика — много десятков рабочих мест работало как unix-терминалы в текстовом режиме. Этот интерфейс был разработан банковскими программистами за полтора месяца самостоятельно. Более того, этот инструмент написания интерфейсов оказался для них более известен (а значит, и более удобен), чем Power Builder. Таким образом, большинство своих небольших по объему задач они реализовали на нем.
Некоторые «продвинутые пользователи» нашей системы привыкли использовать Microsoft' 'Access для построения аналитических запросов. Трудностей не возникло.

On-line проектирование отчетности сторонними системами

На данный момент CustIS Accounting предоставляет семейство представлений (view) БД, которые обеспечивают разнообразные срезы насчитанных отчетных (оперативных и производных) данных. Проектирование печатных и экранных форм для просмотра и печати экранных форм ведется как на «родном» инструментальном средстве (Power Builder) так и сторонними системами генерации отчетов: SQL' 'Reports, Microsoft' 'Access, Microsoft' 'Excel.

Возможность импорта и экспорта данных

В CustIS Accounting реализован единый механизм импорта данных. На данный момент в системе насчитывается около 20 форматов импорта информации, в том числе:

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

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

Кроме этого, в CustIS Accounting реализован собственный механизм передачи любых данных между различными серверами, который по сути является дублирующим к межсерверному обмену, реализованному с помощью репликаций Oracle. В случае, когда качество связи между двумя центрами репликаций нашей системы становится совершенно неудовлетворительным, приходится, к сожалению, пользоваться и этим механизмом. Как это удалось реализовать — в пункте «Распределенность».

Прозрачность

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

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

С проблемой информационной прозрачности тесно связана проблема информационной безопасности, которая рассмотрена в одноименном пункте.

Фискальность и версионность

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

В CustIS Accounting с этой целью реализовано:

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

OLTP+DSS

Возможность сочетать одновременное активное редактирование данных с подготовкой отчетности (OLTP+DSS), требующей объемных консистентных выборок из БД — это такая характеристика сервера базы данных, без которой жить, конечно, можно, но только если Вы готовы мириться с одним из следующих недостатков:

В отчетность могут попадать данные, которые никогда не хранились в БД перманентным образом — следствие так называемых «грязных чтений» (dirty read). Это значит, что, например, кто-то начал редактировать данные, ввел некорректную информацию, правок в БД не записал, а они возьми, да и попади в отчетность.
Пока считается отчет, невозможно изменять данные, которые он использует.

Если Вы справедливо считаете, что оба эти недостатка достаточно серьезны, и что сервер базы данных обязан поддерживать возможность OLTP+DSS, то у Вас не много вариантов — придется выбирать систему, реализованную на Oracle. Только Oracle поддерживает многоверсионность записей, что и позволяет каждому пользователю работать с собственным мгновенным консистентным слепком с БД, не взирая на то, сколько человек и какие именно данные в этот момент меняют.

Информационная безопасность

В данном пункте мы вначале дадим краткое пояснение к подходам, которые применяются при решении проблемы информационной безопасности (далее по пункту — ИБ). А затем более подробно рассмотрим как в CustIS Accounting реализована схема с «жесткой секретностью», и какие именно аспекты поведения пользователей CustIS Accounting позволяет автоматически контролировать (пункт «ИБ в CustIS Accounting»).

Кем обеспечивается ИБ

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

СУБД предоставляют развитый механизм обеспечения ИБ, который можно считать абсолютно надежным. У Oracle, например, за плечами — двадцать лет работы в этом направлении. Нарушение ИБ в результате «подсмотренного» пароля администратора, недобросовестности (халатности) самого администратора являются административными проблемами и к надежности СУБД отношения не имеют.
Если обеспечение ИБ вынесено на уровень клиентского приложения, то у пользователя всегда остается возможность «обойти» это приложение и работать с БД напрямую, в рамках прав доступа, предоставленных сервером самому клиентскому приложению.

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

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

Подход первый — «мягкая секретность»

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

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

Подход второй — «жесткая секретность»

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

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

Если клиентскому приложению, а значит и «искушенному пользователю» разрешено чтение хотя бы одного вида данных (например, документа) из некоторого состава, то он может прочитать ЛЮБЫЕ данные в этом составе полей.
Если клиентскому приложению (нашему «пользователю») разрешено изменять хотя бы один документ (операцию, etc.), то он, скорее всего, сможет изменить и остальные объекты в этой группе. Под «скорее всего» подразумевается то, что в принципе возможно некоторое сужение полномочий с помощью проверок типа «если после изменения таблицы Т1 возникла ситуация Х, то изменения некорректные — правки не вносить». Однако этот механизм весьма и весьма неполноценен ввиду того, что редактирование идет обычно в нескольких таблицах одновременно. Таким образом, вывод, что введена некорректная информация, может быть сделан лишь после анализа всей совокупности введенных данных. А таких средств в СУБД нет.
В схеме «мягкой секретности» достаточно просто «подстелить солому» в виде фискальных копий и всевозможных log-файлов, на порождение которых даже такой «искушенный пользователь» никак повлиять не сможет. Но это всего лишь ответ на вопрос «кто испортил?», а не невозможность такой порчи в принципе.

Сформулируем принципы построения системы с «жесткой секретностью», в соответствии с которыми проектировалась система CustIS Accounting:

ИБ на чтение.

Доступ на чтение таблиц клиентскому приложению, а значит и любому пользователю — закрыт.

2. Чтение данных осуществляется через специальные средства СУБД — представления данных (view). Аппарат достаточно мощный, чтобы пользователь мог увидеть лишь то, что ему положено. При этом стоит оговориться, что при тотальном применении этого аппарата возникает некоторая потеря в производительности и дополнительные затраты при разработке. При некоторых требованиях на ограничение видимости данных они могут быть существенными.

ИБ на обновление или введение новых данных:

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

ИБ в CustIS Accounting

Как уже было сказано, в CustIS Accounting реализована схема с «жесткой секретностью».

Стандартный аппарат прав доступа, предоставляемый СУБД, дополняется в CustIS Accounting следующими правами:

На работу с агрегатами, из которых выделим:

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

На осуществление переходов:

1. право осуществить конкретный переход документа конкретного типа;

2. права на отзыв конкретного перехода;

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

Распределенность

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

Географическая распределенность больших компаний.
Ограниченная мощность одного сервера.

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

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

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

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

Симметрические репликации данных в CustIS Accounting

Механизм репликаций данных — одна из самых сложных областей для проектирования в современных базах данных. Обсуждать его достоинства и недостатки, сравнивать различные схемы репликаций, оценивать то, как это реализовано в различных СУБД — на все это надо потратить не один десяток листов бумаги; поэтому здесь мы это делать не будем. Отметим лишь наиболее очевидное преимущество: СУБД является гарантом консистентного распространения информации с сервера на сервер, с разумными человеческими затратами (на администрирование конфликтов репликаций).

В CustIS Accounting реализована симметрическая схема репликаций данных, представленная на Рис. 6.

Рис. 6 — реализованная симметрическая схема репликаций данных

Механизмом репликации данных в CustIS Accounting обеспечивается:

Передача между серверами всех правил бизнес-логики. Для этого в системе вводятся понятия «разделяемых» и «локальных» бизнес-правил. Изменять можно только локальные бизнес-правила. Когда изменения оттестированы (например, на «отладочном» сервере), их можно:

сделать разделяемыми, и они автоматически распространятся по всем серверам, где эти же правила помечены как «разделяемые»;
отказаться от внесенных изменений, если исправленная локальная версия бизнес-правил признается неудачной. Тогда правила будут восстановлены из разделяемой копии с этого же сервера. Заметим, что время для создания новых бизнес-правил никак не ограничено, так как они хранятся в БД перманентно.

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

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

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

Расходный кассовый ордер: пример реализации в CustIS Accounting конкретного документа

Изложение любых концепций и теорий лучше всего сопровождать примерами. Мы решили показать всю технологическую цепочку реализации типов документов в CustIS Accounting на примере конкретного документа.

В качестве примера был выбран расходный кассовый ордер, который обладает следующими привлекательными чертами:

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

В следующих пунктах этого раздела на примере расходного кассового ордера показано:

Определение атрибутного представления документов — пункт «Атрибуты».
Определение состояний и переходов — пункт «Состояния и переходы».
Смысловое описание планов счетов и проводок для расходного кассового ордера — в пункте «Учетное отражение движения документа — определение проводок».
Определение отражения расходного кассового ордера на планах счетов — в пункте «Действия — операции — шаблоны проводок».
В пункте «Вот и все» подводятся некоторые итоги по описанию документов в CustIS Accounting.

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

В пункте «Нет, это еще не все…» — изменения в связи с Инструкции ЦБ РФ от 27 октября 1997 № 2-П — о расщеплении каждого счета кассы на два: старыми и новыми деньгами.
В пункте «Это еще не все — номер два» — введение в документ многих «символов касплана».
В пункте «План счетов ОПЕРУ» — пример введения нового плана счетов для улучшения учета прохождения документов по отделам.

Атрибуты

Итак, расходный кассовый ордер. Это — документ, на основании которого определенная наличная сумма снимается со счета и выдается определенному лицу.

По результатам предварительного обследования было сформулировано задание на разработку, и документ был отдан в работу. Так в интерактивном ядре CustIS Accounting был заведен тип документа «Расходный кассовый ордер» со следующим набором атрибутов (Рис. 7).

Рис. 7

Состояния и переходы

В общем потоке документооборота цикл жизни расходного кассового ордера не сложен, этот документ:

Заполняется бухгалтером.
Проверяется контролером, который ставит пометку «принято к исполнению».
Поступает кассиру, который, собственно, и выдает требующуюся сумму.

Как видно, в данном случае с документом работают несколько человек. В CustIS Accounting это описывается при помощи последовательных переходов документа из состояния в состояние. Таким образом определяется маршрут документа. В данном случае он не сложен, документ проходит следующие состояния: «Рождение»  «Принято к исполнению»  «Выполнено».

Эти переходы между состояниями, а также собственно состояния, были добавлены в описание типа документа (Рис. 8). Заметим только, что по соглашению состояние «Рождение» — то, в котором любой документ появляется в системе, обозначается как «(‑)» — состояние «минус».

Рис. 8.

Учетное отражение движения документа — определение проводок

Теперь маршрут документа определен. Займемся определением учетных сторон жизни документа.

В CustIS Accounting правила генерации проводок описываются в типах документов, иными словами, проводки не нужно «вводить руками».

Как уже замечалось, весь учет в CustIS Accounting ведется на счетах, организованных в несколько планов счетов. В данном пункте мы дадим смысловое понятие проводок (планов счетов, счетов и сумм), которые отражают движение Расходного кассового ордера по маршруту.

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

Во-вторых, работа с наличностью в кредитных организациях обладает еще одной особенностью: такие операции должны иметь пометки «Символов касплана». «Символы касплана» — это регламентируемые ЦБ РФ пометки «на что выдаются/откуда происходят наличные суммы». Помеченные таким образом суммы входят в соответствующие пункты стандартной банковской отчетности. Отчеты по «символам» имеют явную иерархическую структуру — в общем, в «символах касплана» сразу же угадывается отдельный план счетов — «План счетов символов касплана». Хотя суммы на этих «символах» накапливаются операциями не «с двойной записью», это можно легко исправить, введя два специальных «символа», которые будут выступать парными для любых проводок по «плану счетов символов касплана» — аналоги известных счетов 99999 и 99998 в разделе «В» Основного плана счетов. Таким образом, параллельно проводке в «Основном плане счетов», нужно провести сумму по соответствующему «символу» в «Плане счетов символов касплана».

Действия — операции — шаблоны проводок

Здесь мы рассмотрим, как информация, содержащаяся в документах и структурированная в соответствии с требованиями делопроизводства, то есть весьма произвольно, превращается в тройки «счет дебета, счет кредита, сумму» — информацию, необходимую для совершения проводок. Иными словами, каким же образом параметры проводок (суммы и счета) извлекаются из атрибутов документа?

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

Вернемся к расходному кассовому ордеру. Как мы выяснили, нам требуется совершить две проводки: в «Основном плане счетов» и в «Плане счетов касплана».

На каком переходе документа должны выполняться эти проводки? Понятно, что только тогда, когда деньги реально выданы из кассы — на переходе «Принято к исполнению»  «Выполнено».

Созданные действия на указанном переходе в интерактивном ядре CustIS Accounting показаны на Рис. 9.

Рис. 9.

«РКО/Выполнено» в левой части рисунка — это название перехода из состояния «Принято к исполнению» в состояние «Выполнено». В правой части — два определенных на этом переходе действия. Каждое из действий создает операцию своего типа (столбец «ID-параметр»).

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

Такие правила преобразования — еще один пример картриджей. Описание действия «РКО/Выплачено», которое создает операцию «РКО/Выполнено» и заполняет ее атрибуты из значений атрибутов документа, показано на Рис. 10.

Рис. 10.

Показанный на Рис. 10 алгоритм «Копировать атрибут» — простейший картридж, который проносит значение атрибута документа в (в данном случае одноименный) атрибут операции. В системе реализованы и другие картриджи, которые можно видеть в открытом на Рис. 10 списке.

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

Атрибутное представление операции «РКО/Выполнено» представлено на Рис. 11.

Рис. 11.

При определении операции указывается шаблон проводки, по которому эта операция генерирует проводку. Проводка создается по указанному шаблону проводки и атрибутам операции.

Для примера на Рис. 12 приведена форма определения шаблона проводки в «Основном плане счетов».

Рис. 12

На этой форме представлен целый ряд «картриджей»:

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

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

Общая схема преобразования информации «от документа до проводки» представлена на Рис. 13.

Рис. 13.

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

Вот и все

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

Нет, мы ни в коем случае не утверждаем, что при разработке системы на CustIS Accounting не придется писать программных фрагментов! Мы давно уже поняли, что разрабатывать «системы, где все делается несколькими щелчками мыши» и которые, следовательно, «понятны любой домохозяйке» — бессмысленно. На реальных задачах такие системы либо вообще не могут делать того, что нужно, либо просто стыдливо прячут различные «бейсико-подобные языки», на которых, собственно, и пишется основная часть проекта. Почему-то именно содержательные части никак не удается получить, сколько мышью не щелкай.

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

Тем не менее опыт разработки показал, что «картриджей», этих специализированных алгоритмов в нашей системе требуется не так уж много. В настоящее время в системе реализовано всего около 10 различных алгоритмов поиска счетов дебета/кредита для шаблонов проводок, примерно столько же алгоритмов вычисления сумм проводки и т. д. Всего в системе реализовано около 100 «картриджей» различных типов.

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

Нет, это еще не все…

Действительно, на этом история не закончилась, ее продолжением мы обязаны инструкции ЦБ РФ от 27 октября 1997 № 2-П. Кроме прочего, в ней указывалось, что в преддверии грядущей деноминации кредитным организациям следует существующие кассовые счета расщепить на два: «касса старыми деньгами» и «касса новыми деньгами».

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

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

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

«Это еще не все» — номер два

На этот раз понадобились изменения самим работникам банка. Суть их сводилась к тому, что одну сумму, выдаваемую по расходному кассовому ордеру, нужно разносить по нескольким «символам касплана», а не по одному, как было реализовано. Иными словами, клиент может указать, что он снимает «всего 1000 рублей, из них на зарплату — 500, на командировочные расходы — 100, а остальное — на хозяйственные расходы». Вот все эти подсуммы и требуется разнести по «символам» в зависимости от целей.

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

Доработки были сделаны с привлечением понятия «строк документов». В CustIS Accounting для каждого документа можно указать его «строки». Строки — это обычные агрегаты в системе, они имеют тип и атрибутное представление. Кроме этого, у строк указано, к какому типу документов они относятся. Кроме этого, на переходах документа можно определить действия, которые оперируют со всеми строками указанного типа, относящимися к данному документу. Один тип документов может иметь несколько типов строк, в данном случае нам оказалось достаточно одного такого типа — «Строка расходного касс. ордера».

Атрибутное представление строки показано на Рис. 14. Оно содержит необходимую для проводки по отдельному «символу касплана» информацию.

Рис. 14.

Также было введено новое действие, тип операции и шаблон проводки.

Новое действие порождало по одному экземпляру операции на каждую строку документа (Рис. 15).

Рис. 15.

Эти операции, в свою очередь, по одному и тому же шаблону, генерировали проводки по разным «символам касплана», соответственно тому, какой именно «символ» указан в каждой конкретной строке (вот и реальный пример того, что «шаблоны проводок» являются именно шаблонами) — Рис. 16.

Рис. 16.

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

План счетов ОПЕРУ

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

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

Это хороший пример «произвольного учета». Как уже упоминалось, CustIS Accounting рассчитан на работу с множеством произвольных планов счетов, которые и должны выполнять такого рода «задачи произвольного учета». Для нашей конкретной задачи мы ввели новый план счетов — «План счетов ОПЕРУ».

В простейшем случае «балансовые счета первого и второго порядков» плана счетов ОПЕРУ представляет из себя всего два балансовых счета второго порядка (а счетов «первого порядка» нет совсем), а именно:

Балансовый счет «Общая сумма документов в работе», активный. На нем открывается единственный лицевой счет «Общая сумма документов в работе».
Балансовый счет «Суммы документов в работе по клиентам», пассивный. На нем открываются счета с аналитикой по каждому клиентскому счету в «Основном плане счетов».

Схема проводок проста. Как только принимается в работу документ, который спишет сумму с клиентского счета «А» (дебетует его), совершается проводка Дебет счета «Общая сумма документов в работе» Кредит счета «Сумма документов в работе для счета А» на ожидаемую дебетовую сумму в документе.

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

Когда же документ выполнится, то есть когда пройдет проводка по реальному счету клиента в «Основном плане счетов», следует провести ту же сумму в плане счетов обратно, то есть кредитовать на нее счет «Общая сумма документов в работе», дебетуя счет «Сумма документов в работе для счета А». Таким образом этот выполненный документ перестанет учитываться как «документ в работе».

Схема этих проводок показана на Рис. 17.

Рис. 17.

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

В действительности реализована была более полная схема «Плана счетов ОПЕРУ». И реализация ничем не отличалась от уже описанных действий. Ввели классификатор «Плана счетов ОПЕРУ». Это иерархическая структура «балансовых счетов первого и второго порядков». Она все равно получилась не сложной и представлена на Рис. 18.

Рис. 18.

Здесь введены два «общих балансовых счета второго порядка»:

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

На балансовых счетах «Плат. Док. — Проверено» и «Плат. Док. — На исполнении» открыты лицевые счета с аналитикой по всем счетам клиентов «Основного плана счетов». Это позволило вести более подробный учет «документов в работе». Перенос суммы для расходного кассового ордера выглядит теперь так: «Всего кассовых док. в работе» ⇒ «Плат. Док. — Проверено» ⇒ «Плат. Док. — На исполнении» ⇒ «Всего кассовых док. в работе».

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

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

Рис. 19.

Здесь для вычисления счета дебета используется правило (картридж) «ЛС ОПЕРУ — все кассовые документы», который обращается к уже описанному единственному лицевому счету на балансовом счете второго порядка «Всего кассовых док. в работе».

Счет кредита вычисляется по более сложному правилу «ЛС ОПЕРУ: Аналитика проверено». Это правило ищет на балансовом счете «Плат. Док. — Проверено» лицевой счет, который соответствует указанному в кассовом документе счету из «Основного плана счетов».

Шаблон обратной проводки приведен на Рис. 20.

Рис. 20.

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

Вместо заключения

Надеемся, что нам удалось Вас убедить в том, что CustIS Accounting — это передовая технология автоматизации учета и анализа финансово-хозяйственной деятельности, которая обеспечивает практически все необходимые характеристики, присущие действительно современным технологиям в этой области. Эксплуатация банковской системы подтвердила, что CustIS Accounting:

Является OLTP'+'DSS системой для нескольких сот пользователей.
Ведет любое количество разноплановых учетов через планы счетов.
Контролирует оперативные остатки по счетам и блокированным отчетам.
Обеспечивает адаптивность исключительного качества и позволяет строить произвольную отчетность за счет тотального применения декларативно-функционального подхода.
Обеспечивает информационную надежность, безопасность и прозрачность; фискальность и версионность.
Хорошо интегрируется с другими системами (on-line проектирование отчетности сторонними системами отчето-генерации, импорт-экспорт данных, разработка сторонних on-line приложений).
Является географически распределенной, что обеспечивается симметрической схемой репликации данных.

↑ OnLine Transaction Processing
↑ Large scale decision support
↑ Заметим сразу, что некоторые термины в анкете, возможно, требуют более подробного объяснения. Вся терминология «анкеты» подробно объясняется ниже, в соответствующих пунктах — собственно этим объяснениям и посвящена большая часть данной статьи.
↑ Чем меньше бизнес-логики вынесено при программировании на клиента, тем он «тоньше».
↑ 10 сек — это при работе где-то 25-30 пользователей по вводу документов. Таким образом ввод 10000 документов реально отнимает чуть больше часа.
↑ Сейчас это 25-30 страниц довольно непростого текста.
↑ Заметим, что когда мы говорим о параметрах отчета (датах, счетах), то для их получения мы пользуемся всей мощностью «механизма картриджей» для «вычисления атрибутов агрегата».

[1] OnLine Transaction Processing

[2] Large scale decision support

[3] Заметим сразу, что некоторые термины в анкете, возможно, требуют более подробного объяснения. Вся терминология «анкеты» подробно объясняется ниже, в соответствующих пунктах — собственно этим объяснениям и посвящена большая часть данной статьи.

[4] Чем меньше бизнес-логики вынесено при программировании на клиента, тем он «тоньше».

[5] 10 сек — это при работе где-то 25-30 пользователей по вводу документов. Таким образом ввод 10000 документов реально отнимает чуть больше часа.

[6] Сейчас это 25-30 страниц довольно непростого текста.

[7] Заметим, что когда мы говорим о параметрах отчета (датах, счетах), то для их получения мы пользуемся всей мощностью «механизма картриджей» для «вычисления атрибутов агрегата».

[1]

[2]

[3]

[4]

[5]

[6]

[7]

CustIS Accounting (1998)