7800
правок
Изменения
м
= <big>'''CustIS Accounting – передовая технология автоматизации учета и анализа финансово-хозяйственной деятельности ='''</big><big>'''''Рахтеенко В.Е., Хомюк С.В., Цепков М.А.'''''</big>
== Живой пример ==
=== Предыстория ===
=== История ===
=== Решения ===
=== Сроки ===
=== Результаты и технические характеристики системы ===
: {| cellspacingborder="0" cellpadding1 class="7"wikitable
| <br>
<font color="#000000"> [[File:CustisAccountingPic Рисунок 5.png|542px]] </font>
<font color="#000000"> [[File:CustisAccountingPic Рисунок 6.png|550px]] </font>
Рахтеенко В.Е. Хомюк С.В. Цепков М.А. <br> <div>[#sdfootnote1anc 1]<sup>></sup> OnLine Transaction Processing</div> <div>[#sdfootnote2anc 2]<sup>></sup> Large scale decision support</div> <div>[#sdfootnote3anc 3]<sup>></sup> Заметим сразу, что некоторые термины в анкете, возможно, требуют более подробного объяснения. Вся терминология “анкеты” подробно объясняется ниже, в соответствующих пунктах - собственно этим объяснениям и посвящена большая часть данной статьи.</div> <div>[#sdfootnote4anc 4]<sup>></sup> Чем меньше бизнес-логики вынесено при программировании на клиента, тем он “тоньше”.</div> <div>[#sdfootnote5anc 5]<sup>></sup> 10 сек - это при работе где-то 25-30 пользователей по вводу документов. Таким образом ввод 10000 документов реально отнимает чуть больше часа.</div> <div>[#sdfootnote6anc 6]<sup>></sup> Сейчас это 25-30 страниц довольно непростого текста.</div> <div>[#sdfootnote7anc 7]<sup>></sup> Заметим, что когда мы говорим о параметрах отчета (датах, счетах), то для их получения мы пользуемся всей мощностью “механизма картриджей” для “вычисления атрибутов агрегата”.<references/div>
Нет описания правки
<brblockquote>Статья рассказывает историю создания ядра CustIS Acconting и распределенной АБС на его основе для ЛипецкКомБанка (ЛКБ) примерно за полгода в 1997 году. Работы вызваны изменением с 01.01.1998 банковского плана счетов бухгалтерского учета и ЛКБ принял решение заказать новую систему CUSTIS. Работы начались летом 1997 года, а 1 января система была запущена в боевую эксплуатацию на серверах всех филиалах банка с репликациями метаданных и документов. Статья опубликована в журнале "Компьютер в бухгалтерском учете и аудите" 2-1998.</blockquote>
Сейчас на рынке представлено множество (так и хочется добавить несчетное) программных продуктов, которые позиционируются как "средство для комплексной автоматизации предприятий".
Кроме этого, последняя треть статьи посвящена изложению примера реализации в CustIS Accounting конкретного документа.
Думается, что история написания распределенной банковской системы за 6 месяцев, которая в настоящее время успешно функционирует в самом банке и нескольких его филиалах - это очень живой пример.
Наша компания в течение последних 3-х лет занималась разработкой заказных систем автоматизации и учета для торговых компаний и банков. Характерная черта этих разработок - большое разнообразие предметных областей: от управленческого учета и многоуровневого маркетинга в торговых компаниях до автоматизации торгов ГКО/ОФЗ и отделов дилинга в банках.
Постепенно стала возникать концепция “общей схемы автоматизации” и инструментария, который эффективно ее строит. К середине 1997 года у нас была готова (изложена на бумаге) концепция таких “общих систем автоматизации” и техническое задание на CustIS Accounting - соответствующего инструментального средства. Фактически CustIS Accounting - это универсальное ядро произвольной системы автоматизации, которое потом “обрастает” конкретным содержанием. Заметим сразу, что CustIS Accounting предоставляет средства для всего спектра потребностей систем автоматизации: документооборота, бухгалтерии и произвольных учетных систем и аналитических отчетов по ним.
В середине того же 1997 года наша компания получает заказ на автоматизацию банка. Характерные черты разработки:
Огласим принятые тогда решения, полученные результаты и, быть может, самое интересное - сроки.
Учитывая сжатые сроки разработки, было решено реализовать CustIS Accounting - инструмент для эффективного наполнения системы содержанием. В частности, CustIS Accounting должен был предоставить декларативные объектно-ориентированные средства описания предметной области.
Разработка системы на CustIS Accounting преследовала, кроме прочего, еще одну цель - расширить коллектив разработчиков экспертами со стороны заказчика. Как показало дальнейшее, это было правильное и, возможно, единственно верное решение.
Огласим повременную раскладку разработки:
* 2 месяца (ноябрь-декабрь) - настройка конкретной реализации, т.е. наполнение ядра CustIS Accounting содержательной частью банковской системы.
На данный момент система эксплуатируется в головном банке и во всех его подразделениях.
|-
| Технические характеристики системы
|-
| Система управления базой данных (СУБД)
Итак, идеальная система автоматизации должна, на наш взгляд, обладать следующими характеристиками:
* Обеспечивать быстрый одновременный доступ ('''OLTP[#sdfootnote1sym <supref>1OnLine Transaction Processing</supref>]''') к актуальным данным нескольких сот пользователей.
* Предоставлять ведение '''разнопланового учета''' (учета в разных планах счетов) с максимально интересующей подробностью.
* Обеспечивать '''оперативный контроль''' за текущими состояниями. Например - остатки по счетам, состояния складов, обязательств и т.д.
* Поддерживать '''фискальность и версионность''', т.е. всякое изменение информации в системе авторизовано, и ведется история версий информации.
* Возможность одновременного активного редактирования данных и подготовки массивной отчетности (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. Сколько конкурентных пользователей предполагается на сервер? От 1 до 10 = 0 баллов, 10‑100 = 50 баллов, 100‑1000 = 200 баллов</font>
| <br>
|-
Ваши результаты.
{| cellspacingborder="0" cellpadding1 class="7"wikitable
|-
| '''Вы набрали'''
Именно поэтому в этом же пункте мы покажем, что принятые нами проектные решения позволяют обеспечить достаточную в реальной жизни производительность.
=== Надежная и мощная СУБД � - Oracle ===
Перепробовав в процессе роста компании и решаемых ею задач следующие варианты:
=== Надежность проектных решений ===
На наш взгляд, 80% процентов успеха проекта определяется качеством разработки серверной части системы. При этом необходимым условием является использование '''очень тонкого[#sdfootnote4sym <supref>4Чем меньше бизнес-логики вынесено при программировании на клиента, тем он "тоньше".</supref>] клиента'''. Обосновать это можно следующими соображениями:
* Большие системы тяготеют к тому, чтобы доступ к БД осуществлялся несколькими разными клиентскими приложениями. Таким образом, для повышения информационной надежности системы, контроль целостности данных должен выноситься на сервер, иначе любое новое клиентское приложение может (при некорректной работе) привести к разрушению целостности данных.
* По этой же причине на серверную часть выносится и основная часть бизнес-логики системы. В CustIS Accounting '''на сервер вынесена вся бизнес-логика'''.
* Число проводимых документов в день: 1000-10000 штук.
* Время совершения перехода документа = 0.1-1 сек.
* Время ввода документа (естественно, в конкурентной работе) = 1-10 сек[#sdfootnote5sym <supref>510 сек - это при работе где-то 25-30 пользователей по вводу документов. Таким образом ввод 10000 документов реально отнимает чуть больше часа.</supref>].
Эти данные показывают, что, во-первых, на имеющихся серверах система функционирует с вполне приличной производительностью, а во-вторых, имеется большой запас для повышения производительности путем прямого улучшения аппаратной части серверов - '''масштабируемость''' Oracle прекрасно позволяет это делать.
Второй вопрос, который естественно вытекает из первого, такой: “'''Что такое план счетов в терминах CustIS Accounting?'''”.
К сожалению, чтобы ввести точное формальное определение понятия “плана счетов”, реализованного в CustIS Accounting, надо излагать достаточно объемные теоретические построения[#sdfootnote6sym <supref>6Сейчас это 25-30 страниц довольно непростого текста.</supref>]. Поэтому здесь мы ответим на этот вопрос неформально, попытаемся на разнообразных примерах дать по возможности верное представление.
* В терминах рисунка “Принципы построения системы” (Рис. 1) план счетов - это один прямоугольник внутри прямоугольника "Разные системы учета".
* Любой учетный регистр, который есть в системе (учетное значение, или, совсем грубо говоря “число, которое вас интересует”), - это значение какого-то счета в каком-то плане счетов. Изменение значений на счетах может производиться только проводками (по правилам двойной записи). Проводки в системе могут появиться только как результат изменения состояния некоторого документа (на схеме "Принципы построения системы" - Рис. 1 - это внутри квадратика "Документооборот").
Самыми примитивными картриджами сбора данных для отчетности, т.е. анализа '''Acc''''''(''''''t'''''')''', являются:
* Рассчитать и запомнить остаток по счету такому-то на дату такую-то.
* Рассчитать и запомнить оборот по дебету и/или кредиту счета такого-то с даты такой-то по дату такую-то[#sdfootnote7sym <supref>7Заметим, что когда мы говорим о параметрах отчета (датах, счетах), то для их получения мы пользуемся всей мощностью "механизма картриджей" для "вычисления атрибутов агрегата".</supref>].
Для исчисления (а, значит, и анализа) функций, являющихся производными функциями от композиции функций '''Acc''''''(''''''t''''''),''' в CustIS Accounting используется понятие '''балансовых классификаторов'''. Каждый балансовый классификатор это организованное в иерархию множество объектов, каждый из этих объектов называется '''балансовый счет'''. Приведем примеры наиболее очевидных балансовых классификаторов:
Атрибутное представление показано на Рис. 4.
Рис. 4
Настроечный диалог системы для этого случая показан на Рис. 5.
Рис. 5.
* Является географически '''распределенной''', что обеспечивается симметрической схемой репликации данных.
[[Категория:Статьи]]