Изменения

= <big>'''CustIS Accounting – Accounting — передовая технология автоматизации учета и анализа финансово-хозяйственной деятельности ='''</big>

<brbig>'''''Рахтеенко&nbsp;В. Е., Хомюк&nbsp;С. В., Цепков&nbsp;М. А.'''''</big>

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

Если Вы почитаете рекламные материалы Статья опубликована в журнале '''«Компьютер в бухгалтерском учете и поговорите с персоналом фирмы, производящий продукт, то с некоторым раздражением заметите, что все предлагаемые продукты на первый взгляд одинаковы: все “идут от документа”, все “работают в технологии клиентаудите» 2-сервер”, практически все имеют версию системы, работающую на Oracle и т.д1998'''.</blockquote>

“Ну хорошо”, [[Файл:CustisAccounting- говорите Вы, 1998- “а как обстоит дело с предметной частью? Какая именно система лучше всего удовлетворяет именно мои потребности?”. Ответ на этот вопрос, возможно, также вызовет Ваше недоумение - с первого взгляда буквально во всех системах есть все, что Вам нужно и даже больше того, что нужноcover.jpg|right|400px]]

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

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

== Живой пример ==

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

=== Предыстория ===

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

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

=== История ===

* Банк имеет семь удаленных филиалов (общая удаленность около 600 км600 км, качество связи от “удовлетворительного” «удовлетворительного» до “плохого”«плохого», а временами и “совершенно неудовлетворительного”«совершенно неудовлетворительного»).

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

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

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

=== Решения ===

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

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

=== Сроки ===

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

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

: {| cellspacingborder="0" cellpadding1 class="7"wikitable

* Около 80 типов ''документов'', среди них - них — 30 типов ''отчетов'', 150 типов ''агрегатов'' (объектов - объектов — не являющихся ''документами'').

* Пользовательский интерфейс насчитывает около 250 экранных форм. ''Агрегаты'' и ''документы'' редко используемых типов редактируются через единый “администраторский” «администраторский» интерфейс Ядра CustIS Accounting.

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

* Обеспечивать быстрый одновременный доступ ('''OLTP[#sdfootnote1sym <supref>1OnLine Transaction Processing</supref>]''') к актуальным данным нескольких сот пользователей.

* Обеспечивать '''оперативный контроль''' за текущими состояниями. Например - Например — остатки по счетам, состояния складов, обязательств и&nbsp;т.д.* Обладать свойством '''адаптивности''', т.е. то есть схема учета должна быть достаточно гибкой, чтобы изменение правил учета можно было производить на “живой” «живой» системе. В идеале изменение бизнес-логики должно производиться конечным пользователем с правами администратора прикладной части системы (экспертом-прикладником).

* возможность импорта и экспорта данных, в т.ч. том числе в многомерные базы данных (OLAP);

* Обладать '''прозрачностью''', т.е. то есть каждый пользователь системы работает:

* Поддерживать '''фискальность и версионность''', т.е. то есть всякое изменение информации в системе авторизовано, и ведется история версий информации.* Возможность одновременного активного редактирования данных и подготовки массивной отчетности (DSS[#sdfootnote2sym <supref>2Large scale decision support</supref>]). Т.е. То есть '''OLTP+DSS'''.

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

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

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

{| cellspacingborder="0" cellpadding1 class="7"wikitable

| <font color="#000000">OLTP. Сколько конкурентных пользователей предполагается на сервер? От&nbsp;1&nbsp;до&nbsp;10 = 0&nbsp;баллов, 10‑100 = 50&nbsp;баллов, 100‑1000 =&nbsp;200&nbsp;баллов</font>| <br/>

| <br/>

| <br/>

| <br/>

| В существующих системах прикладная часть устраивает: полностью&nbsp;(99‑10099‑100 %)&nbsp;=&nbsp;0&nbsp;баллов, в основном&nbsp;(~9090 %)&nbsp;=&nbsp;5&nbsp;баллов, отсутствует несколько важных разделов(~8080 %)&nbsp;=&nbsp;10&nbsp;баллов, похожа на то, что Вам нужно, но только в общих чертах&nbsp;(~5050 %)&nbsp;=&nbsp;100&nbsp;баллов, ничего похожего на рынке не обнаружено&nbsp;(00 %)&nbsp;=&nbsp;500&nbsp;баллов| <br/>

| <br/>

| <br/>

| <br/>

| <br/>

| <br/>

| <br/>

<br/>

{| cellspacingborder="0" cellpadding1 class="7"wikitable

| Скорее всего Вам нужна "коробочная" «коробочная» дешевая программа. Ваше счастье - счастье — проблемы серьезной автоматизации пока не Ваши проблемы.

| Скорее всего Вам удастся купить дорогую "коробочную" «коробочную» программу.

| Если Вы наберетесь терпения, и правильно выберете фирму контрагента, то Вы можете получить доработанную под Вас дорогую "коробочную" «коробочную» программу.

И если Вы выберете не ту "коробку" - «коробку» — мужайтесь.

| Вы наш клиент. Задач подобных этой у нас реализовано около 10. Ориентировочный срок реализации - реализации — 3‑9 месяцев.

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

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

| Приходите, посмотрим, что можно сделать...сделать…

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

[[File:CustisAccountingPic Рисунок 2CustisAccountingPic2.png|550px]]

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

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

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

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

* Microsoft Access (строго говоря это даже “БД” «БД» назвать нельзя, но работали мы с этим продуктом 4 года назад, потому и упоминаем).

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

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

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

На наш взгляд, 8080 % процентов успеха проекта определяется качеством разработки серверной части системы. При этом необходимым условием является использование '''очень тонкого[#sdfootnote4sym <supref>4Чем меньше бизнес-логики вынесено при программировании на клиента, тем он «тоньше».</supref>] клиента'''. Обосновать это можно следующими соображениями:

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

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

* '''Основной функционал системы''' (что есть “основной функционал” «основной функционал» рассмотрено в пункте "симбиоз «симбиоз декларативного и функционального подхода"подхода») также '''не изменяется'''. На данный момент этот функционал оттестирован и находится в промышленной эксплуатации нескольких сот пользователей на семи разных серверах.

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

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

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

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

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

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

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

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

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

* Время ввода документа (естественно, в конкурентной работе) = 1-10&nbsp;сек[#sdfootnote5sym <supref>510 сек — это при работе где-то 25-30 пользователей по вводу документов. Таким образом ввод 10000 документов реально отнимает чуть больше часа.</supref>].

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

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

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

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

К сожалению, чтобы ввести точное формальное определение понятия “плана счетов”«плана счетов», реализованного в CustIS Accounting, надо излагать достаточно объемные теоретические построения[#sdfootnote6sym <supref>6Сейчас это 25-30 страниц довольно непростого текста.</supref>]. Поэтому здесь мы ответим на этот вопрос неформально, попытаемся на разнообразных примерах дать по возможности верное представление.* В терминах рисунка “Принципы «Принципы построения системы” системы» (Рис. 1) план счетов - счетов — это один прямоугольник внутри прямоугольника "Разные «Разные системы учета"учета».* Любой учетный регистр, который есть в системе (учетное значение, или, совсем грубо говоря “число«число, которое вас интересует”интересует»), -  — это значение какого-то счета в каком-то плане счетов. Изменение значений на счетах может производиться только проводками (по правилам двойной записи). Проводки в системе могут появиться только как результат изменения состояния некоторого документа (на схеме "Принципы «Принципы построения системы" - системы» — Рис. 1 - 1 — это внутри квадратика "До­ку­мен­то­о­бо­рот"«До­ку­мен­то­о­бо­рот»).

* Текущие (оперативные) остатки на счетах соответствуют концу некоторой фиксированной даты, которая называется “датой «датой плана счетов”счетов», и хранится в атрибутах плана счетов. Изменение этой даты называется “сменой «сменой даты плана счетов”счетов», и, как правило, делается одним или несколькими переходами этого плана счетов (см. пояснения и Рис.&nbsp;2).

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

* Даты разных планов счетов могут быть разными. Это объясняется тем, что часто один вид учета принципиально “отстает” «отстает» от другого.

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

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

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

[[File:CustisAccountingPic Рисунок 3CustisAccountingPic3.png|446px]]

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

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

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

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

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

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

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

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

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

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

* <br/>

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

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

* <br/>

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

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

* <br/>

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

* <br/>

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

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

* <br/>

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

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

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

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

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

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

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

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

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

[[File:CustisAccountingPic Рисунок 4CustisAccountingPic4.png|548px]]

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

<font color="#000000"> [[File:CustisAccountingPic Рисунок 5CustisAccountingPic5.png|542px]] </font>

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

<font color="#000000"> [[File:CustisAccountingPic Рисунок 6CustisAccountingPic6.png|550px]] </font>

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

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

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

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

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

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

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

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

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

* Ведение истории проводок на одно поколение, т.е. то есть хранятся действующие и предпоследние проводки, сгенерированные из-под одной и той же операции. Такие “пары проводок” «пары проводок» возникают в результате отзыва перехода документа и повторного его выполнения, быть может с другими данными.

Возможность сочетать одновременное активное редактирование данных с подготовкой отчетности ('''OLTP+DSS'''), требующей объемных консистентных выборок из БД - БД — это такая характеристика сервера базы данных, без которой жить, конечно, можно, но только если Вы готовы мириться с одним из следующих недостатков:* В отчетность могут попадать данные, которые никогда не хранились в БД перманентным образом - образом — следствие так называемых "грязных чтений" «грязных чтений» (dirty read). Это значит, что, например, кто-то начал редактировать данные, ввел некорректную информацию, правок в БД не записал, а они возьми, да и попади в отчетность.

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

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

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

* Принятой практикой является хранение однородной информации в одной таблице. Грубо говоря, это значит, что есть таблицы “все «все документы определенного рода” рода» или просто “все документы”«все документы».

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

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

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

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

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

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

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

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

# Доступ на модификацию таблиц пользователю - пользователю — закрыт.

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

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

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

[[File:CustisAccountingPic Рисунок 7CustisAccountingPic7.png|549px]]

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

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

* сделать разделяемыми, и они автоматически распространятся по всем серверам, где эти же правила помечены как “разделяемые”«разделяемые»;

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

* “Цикл жизни” «Цикл жизни» расходного кассового ордера не сложен.

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

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

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

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

[[File:CustisAccountingPic Рисунок 8CustisAccountingPic8.png|552px]] Рис. 7

# Проверяется контролером, который ставит пометку “принято «принято к исполнению”исполнению».

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

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

[[File:CustisAccountingPic Рисунок 9CustisAccountingPic9.png|549px]]

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

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

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

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

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

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

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

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

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

[[File:CustisAccountingPic Рисунок 10CustisAccountingPic10.png|553px]]

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

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

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

[[File:CustisAccountingPic Рисунок 11CustisAccountingPic11.png|528px]]

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

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

[[File:CustisAccountingPic Рисунок 12CustisAccountingPic12.png|550px]]

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

[[File:CustisAccountingPic Рисунок 13CustisAccountingPic13.png|547px]]

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

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

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

[[File:CustisAccountingPic Рисунок 14CustisAccountingPic14.png|525px]]

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

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

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

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

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

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

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

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

=== “Это «Это еще не все” - все» — номер два ===

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

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

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

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

[[File:CustisAccountingPic Image 14CustisAccountingPic15.png|329px]]

[[File:CustisAccountingPic Объект1CustisAccountingPic16.png|304px]]

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

[[File:CustisAccountingPic Рисунок 17CustisAccountingPic17.png|548px]]

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

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

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

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

В простейшем случае “балансовые «балансовые счета первого и второго порядков” порядков» плана счетов ОПЕРУ представляет из себя всего два балансовых счета второго порядка (а счетов “первого порядка” «первого порядка» нет совсем), а именно:# Балансовый счет “Общая «Общая сумма документов в работе”работе», активный. На нем открывается единственный лицевой счет “Общая «Общая сумма документов в работе”работе».# Балансовый счет “Суммы «Суммы документов в работе по клиентам”клиентам», пассивный. На нем открываются счета с аналитикой по каждому клиентскому счету в “Основном «Основном плане счетов”счетов».

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

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

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

[[File:CustisAccountingPic Рисунок 18CustisAccountingPic18.png|330px]]

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

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

[[File:CustisAccountingPic Рисунок 19CustisAccountingPic19.png|366px]]

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

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

[[File:CustisAccountingPic Рисунок 20CustisAccountingPic20.png|547px]]

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

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

[[File:CustisAccountingPic Рисунок 21CustisAccountingPic21.png|547px]]

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

Рахтеенко&nbsp;В.Е. Хомюк&nbsp;С.В. Цепков&nbsp;М.А. <br>  <div>[#sdfootnote1anc 1]^> OnLine Transaction Processing</div> <div>[#sdfootnote2anc 2]^> Large scale decision support</div> <div>[#sdfootnote3anc 3]^> Заметим сразу, что некоторые термины в анкете, возможно, требуют более подробного объяснения. Вся терминология “анкеты” подробно объясняется ниже, в соответствующих пунктах - собственно этим объяснениям и посвящена большая часть данной статьи.</div> <div>[#sdfootnote4anc 4]^> Чем меньше бизнес-логики вынесено при программировании на клиента, тем он “тоньше”.</div> <div>[#sdfootnote5anc 5]^> 10 сек - это при работе где-то 25-30 пользователей по вводу документов. Таким образом ввод 10000 документов реально отнимает чуть больше часа.<references/div> <div>[#sdfootnote6anc 6]^> Сейчас это 25-30 страниц довольно непростого текста.</div> <div>[#sdfootnote7anc 7]^> Заметим, что когда мы говорим о параметрах отчета (датах, счетах), то для их получения мы пользуемся всей мощностью “механизма картриджей” для “вычисления атрибутов агрегата”.</div>