Архитектура системы - очень важное понятие. Она (архитектура) определяет возможности и удобство системы. Перед тем, как рассматривать архитектуру www.hubcloud.ru давайте познакомься с самим понятием архитектуры, на каком-нибудь всем известном примере (тогда нам проще будет понять архитектуры других систем).
Рассмотрим для примера архитектуру Excel. С Excel знакомы все, на Excel решено больше учетных задач, чем на любом другом ПО в мире.
(!) Excel - самое успешное бизнес-ПО в мире. Интересно, а почему? Ведь архитектура Excel и его сервисные возможности совсем не подходят для учетных систем. Потому что Excel конструктор (1), в котором пользователь ни от кого независим (2). И это становится самым значительным преимуществом для учетных задач с их сверхвысоким разнообразием.
В Excel можно выделить 3 основных типа объектов работающих с данными:
- ячейку (с адресом: файл_лист_столбец_строка)
- синтаксис формул, который связывает ячейки (“ячейка1” <функция Excel> “ячейка2”)
- сводные таблицы
(!) К отдельному типу объектов можно было бы отнести PowerQuery c PowerPivot, но это пока мало распространенные инструменты, поэтому опустим их. Форматирование, группировку строк, фильтрацию, схемы-рисунки и 1 млн всех прочих инструментов, считаем не основными типами объектов или сервисными функциями. Макросы на VB отнесем к программированию, и тоже оставим за скобками.
Теперь давайте разделим всех пользователей Excel на две группы, на тех кто пользуется “формулами и инструментами массива” и тех, кто не пользуется (это позволит более явно продемонстрировать понятие архитектуры).
(!) К “формулам и инструментам массива” отнесем “Сводную таблицу” и формулы массива: ИНДЕКС, ПОИСКПОЗ, ДВССЫЛ, СУММЕСЛИМН, ВПР и пр.
Почему первая категория пользователей считает Excel важным, нужным и полезным инструментом - абсолютно понятно. Потому что использование “инструментов массива” в Excel - это приближение к программным способам обработки данных (без потребности в навыках программирования).
А вот почему вторая категория пользователей находит Excel полезным и эффективным инструментом? Что в архитектуре ячейка-формула делает его эффективным при использовании простых формул (даже без использования инструментов массивов)? Это «что», это масштабирование расчетов. Именно “масштабирование расчетов” и делает Excel удобным и эффективным инструментом.
Масштабирование расчетов в Excel реализовывается с помощью двух сервисов:
- “протягивания и копирования формул” (относительные и абсолютные ссылки, замены в формулах и т.д.). Именно этот механизм и позволяет значительно упрощать процесс расчетов. Внесли формулу в первой строку, и протянули ее на все 100 000 строк таблицы. Что было бы если бы вам нужно было писать 100 000 формул руками?
- “автоматический пересчет при изменении значений в ячейке”
Тогда архитектуру Excel можно было бы описать, так: “Excel имеет два объекта: ячейку с адресом (1) и механизм формул, который связывает любые ячейки (2). И два сервиса: сервис копирования формул (3) и сервис автоматического пересчета (4)”. См. рисунок ниже.
Теперь рассмотрим вопрос, а какова идеальная архитектура для учетной системы? Мы говорим пока только об объектах, не учитывая сервисы.
Рассмотрим несколько самых общих ситуаций, на которых можно продемонстрировать общую модель документооборота в учете.
Представьте деревню, крестьяне которой должны раз в год сдавать подать (налог). Какие объекты учета должны бы были присутствовать в этом кейсе? Скорее всего в учете были:
- некие ”списки”, например крестьян, домов и т.д., с чего/кого собирался налог.
- “первичный документ”, некая квитанция, ведомость, фиксирующая событие сдачи подати, которая отдавалась крестьянину, в знак того, что он сдал налог.
- “запись в амбарной книге”, отражение события в учетной книге, причем отражение в таком формате, чтобы было удобно подсчитывать агрегированные показатели, скорее всего с использованием двойной записи, с одной стороны списание долгов крестьян, с другой стороны перечень полученных от крестьян материальных ценностей.
- “рапорт” (отчет) о поездке с итоговыми суммами собранных материальных ценностей.
Рассмотрим еще один пример. Банк и платежное поручение. Раньше, до широкого распространения клиент-банков, для отправки платежа требовалось распечатать на бумаге “платежное поручение” и доставить его в банк. Кстати, само слово “поручение” - это от фразы “моя компания поручает вашему банку оплатить”.
Ранее в информационных системах 1С 7.0 и 1С 8.0 были такие операции, как “платежное поручение (исх.)” и “платежное поручение (вх.). В более поздних версиях 1С эти операции превратились в “поступление дс на счет” и “списание дс со счета”. Видимо, потому что уже никто не приезжает физически в банк и не приносит бумажные “платежные поручения”.
Сам бумажный документ исчез, но понятие о нем осталось в учете. До сих пор, если ожидаемый платеж “не проходит”, то продавец может попросить покупателя скинуть “платежку с отметкой банка”, которая представляет из себя электронный документ в pdf, с синим штампом, но поставленным (скорее всего) программно. Некая бутафорская “дань старине”. То есть документ на бумаге ушел в прошлое, но понятие о нем осталось.
Ну и конечно в учете банка присутствуют списки, записи, но уже не в “амбарных книгах”, а в электронных таблицах удобного для получения отчетов формата.
Принципиально в документообороте учета ничего не поменялось. И скорее всего не поменяется и в будущем, даже после того, как все документы станут электронными или даже когда бухгалтера и экономиста заменит робот, все равно в учете (и в информационной системе) останутся понятия о:
- списках (что учитываем)
- операциях (суть которых зафиксировать какое-то событие, аналоги “бумажных первичных документов” но только в системе)
- журналах (то как мы , в удобном для нас формате, отразим в учете операцию, аналоги “амбарных книг”)
- отчетах (которые легко получить из журналов, так как сконструировали их удобными для обработки и информации).
В архитектуре HubCloud.io есть 4 типа объектов, которые соответствуют описанному выше, а именно:
- Справочники (любые “списки”)
- Операции (аналог “первичного документа”)
- Журналы (аналог “амбарных книг”)
- Отчеты (“отчеты”)
(!) И отдельно, раз мы говорим об автоматизации расчетов, то есть еще “плюс один” объект системы, который автоматизирует расчеты в системе.
- Механизмом расчетов с использованием «функций и выражений» (аналог функций в Excel)
Итого, в HubCloud.io 5 объектов. Каждый из объектов обладает своими свойствами, характеристиками и возможностями.
(!) То что было в Excel ячейкой с адресом (файл_лист_столбец_строка) и синтаксисом формул, это стало в HubCloud.io справочником-операцией-журналом-отчетом-механизмом расчетов“.
То что было в Excel сервисом “копирования формул и автоматическим пересчетом”, вошло в HubCloud.io в механизм расчетов. Дополнительно к сервисам в HubCloud.io относится то, что является сервисом принятым в учетных системах: логирование и ограничение прав доступа к любой информации, история изменения, “двойная запись”, ввод на основании и прочее...
Кратко мы коснемся этой области в данной статье, а подробно прочесть можно будет в соответствующих инструкциях.
Опишем чуть более подробно.Справочники – вся справочная информация, любые списки и перечисления: сотрудники, подразделения, статьи затрат, склады и номенклатура, типы скидок и прочее.
Операции – это объект, которым отражаются все события, (действия) в системе. Это и приход товаров, и оплата, и прием на работу, и заявка на оплату,и продажа товаров и так далее. На этом уровне производится подавляющее большинство всех расчетов в системе.
Отчеты – это сгруппированная, адаптированная для понимания пользователем, информация.
Синтаксис функций и выражений – это набор функций, выражений, с помощью которого настраиваются все расчеты в сервисе HubCloud.io Этот инструмент чем то напоминает формулы в Excel. Отличие от Excel в том, что синтаксис в HubCloud.io направлен больше на действия с таблицами, а не с числами. На схеме потоки 2,3,4,5,6 реализованы «функциями и выражениями».
Журналы – промежуточный объект между операциями и отчетами. Журналы перегруппировывают учетную информацию. Легче всего это понять на примере.
Пример 1. Взаиморасчеты. На взаиморасчеты влияют очень много операций. Это оплаты и возвраты денег, продажи и возвраты товара, акты взаимозачетов и переуступка долга, кредит-ноты и прочее. Чтобы не «собирать» взаиморасчеты из разных операций, можно собрать информацию из этих операций в одном месте (в одной таблице). То есть создать один Журнал, где собрать вместе всю информацию, которая относится к взаиморасчетам.
Пример 2. Операция «оплата ДС» должна изменить расчеты и контрагентом (1), уменьшить остатки ДС (2) и уменьшить остаток возможного к расходу бюджета (3). Для этих трех различных целей мы создадим отдельные Журнал. И одна операция сделает много движений в трех разных журналах, каждый из которых служит своей цели.
Пример 3. В компании существует процесс поставки из четырех последовательных этапов:
(1) заказ покупателя => (2) заказ поставщику => (3) поставка от поставщика=> (4) поставка покупателю
У нас в учете будут четыре операции, но нам нужно видеть разницу между парами операций (одна операция минус другая операция).
(1)–(2); (2) –(3); (3)–(4); (1)–(4). Каждая из этих действий будет иметь свой смысл.
(1)–(2): это остаток заказа клиента, который не заказ у поставщика
(2) –(3): остаток, который должен поставить поставщик.
(3)–(4): остаток, который мы получили от поставщика, но не отгрузили клиенту
(1)–(4): что осталось отгрузить клиенту по заказу.
(!) Понимание роли Журналов - это одна из базовых, центральных объектов учетной системы. Наличие журналов позволяет перегруппировать информацию из операций в том виде, в котором она потребуется нам для дальнейших вычислений и отчетов. Мы можем создавать любое количество журналов и каждый журнал может служить для своей цели (целей).
Схематично архитектуру HubCloud.io можно представить в виде следующей схемы.
(!) Пояснения к схеме: сверху написаны объекты системы. Снизу, как можно их представить, если бы мы говорили языком Excel. Стрелочки означают нечто эфемерное, что можно назвать “информационные потоки”. Стрелка (1) - означает, что в справочниках можно настраивать ссылку друг на друга. Стрелка (2) означает, что поля в Операциях - это ссылка на справочники. Стрелка (3) - символизирует, что в операции мы настраиваем любые расчеты, используя поля и формулы (как в Excel). Стрелка (4) означает, что мы записываем операции (“первичные документы”) в журналы (“проводки в амбарных книгах”). Более подробно о журналах читайте в этой же главе чуточку ниже. Стрелка (5) означает, что мы можем получать данные из Журналов и использовать их в расчетах, это некие выражения, которые позволяют работать с таблицами, аналог формул массивов в Excel, только более широким функционалом. Стрелка (6) означает, что при формировании отчетов мы также используем некие “функции и выражения”, например, как сводная таблица в Excel.
Подведем итоги главы: Мы познакомились с объектами в HubCloud.io.
К этому моменту у нас есть ER-модель нашего СКВОЗНОГО ПРИМЕРА , есть алгоритм перехода от ER-модели к таблицам. Мы кратко ознакомились с объектами в системе HubCloud.io. Теперь мы можем приступить к реализации СКВОЗНОГО ПРИМЕРА в системе HubCloud.io