2.2 Знакомство с архитектурой A-techs | A-TECHS

2.2 Знакомство с архитектурой A-techs

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

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

 


(!) Excel — самое успешное бизнес-ПО в мире. Интересно, а почему? Ведь архитектура Excel и его сервисные возможности совсем не подходят для учетных систем. Потому что Excel конструктор (1), в котором пользователь  ни от кого независим (2). И это становится самым значительным преимуществом для учетных задач с их сверхвысоким разнообразием.


 

В Excel можно выделить 3 основных типа объектов работающих с данными:

  1. ячейку (с адресом: файл_лист_столбец_строка)
  2. синтаксис формул, который связывает ячейки (“ячейка1”   <функция Excel> “ячейка2”)
  3. сводные таблицы

 


(!) К отдельному типу объектов можно было бы отнести PowerQuery c PowerPivot, но это пока мало распространенные инструменты, поэтому опустим их. Форматирование, группировку строк, фильтрацию, схемы-рисунки и 1 млн всех прочих инструментов, считаем не основными типами объектов или сервисными функциями. Макросы на VB отнесем к программированию, и тоже оставим за скобками.


 

Теперь давайте разделим всех пользователей Excel на две группы, на тех кто пользуется “формулами и инструментами массива” и тех, кто не пользуется (это позволит более явно продемонстрировать понятие архитектуры).

 


(!) К “формулам и инструментам массива” отнесем “Сводную таблицу” и формулы массива: ИНДЕКС, ПОИСКПОЗ, ДВССЫЛ, СУММЕСЛИМН, ВПР и пр.


 

Почему первая категория пользователей считает Excel важным, нужным и полезным инструментом — абсолютно понятно. Потому что использование “инструментов массива” в Excel — это приближение к программным способам обработки данных (без потребности в навыках программирования).

 

А вот почему вторая категория пользователей находит Excel полезным и эффективным инструментом? Что в архитектуре ячейка-формула делает его эффективным при использовании простых формул (даже без использования инструментов массивов)? Это «что», это масштабирование расчетов. Именно “масштабирование расчетов” и делает Excel удобным и эффективным инструментом.

 

Масштабирование расчетов в Excel  реализовывается с помощью двух сервисов:

  1. “протягивания и копирования формул” (относительные и абсолютные ссылки, замены в формулах и т.д.). Именно этот механизм и позволяет значительно упрощать процесс расчетов. Внесли формулу в первой строку, и протянули ее на все 100 000 строк таблицы. Что было бы если бы вам нужно было писать 100 000 формул руками?
  2. “автоматический пересчет при изменении значений в ячейке”

 

Тогда архитектуру Excel можно было бы описать, так: “Excel имеет два объекта: ячейку с адресом (1) и механизм формул, который связывает любые ячейки (2). И два сервиса: сервис копирования формул (3) и сервис автоматического пересчета (4)”. См. рисунок ниже.

 

______________2019-03-05___15.57.08.png

 

Теперь рассмотрим вопрос, а какова идеальная архитектура для учетной системы? Мы говорим пока только об объектах, не учитывая сервисы.

 

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

Представьте деревню, крестьяне которой должны раз в год сдавать подать (налог). Какие объекты учета должны бы были присутствовать в этом кейсе? Скорее всего в учете были:

  1. некие ”списки”, например крестьян, домов и т.д., с чего/кого собирался налог.
  2. первичный документ”, некая квитанция, ведомость, фиксирующая событие сдачи подати, которая отдавалась крестьянину, в знак того, что он сдал налог.
  3. запись в амбарной книге”, отражение события в учетной книге, причем отражение в таком формате, чтобы было удобно подсчитывать агрегированные показатели, скорее всего с использованием двойной записи, с одной стороны списание долгов крестьян, с другой стороны перечень полученных от крестьян материальных ценностей.
  4. рапорт” (отчет) о поездке с итоговыми суммами собранных материальных ценностей.

Рассмотрим еще один пример. Банк и платежное поручение. Раньше, до широкого распространения клиент-банков, для отправки платежа требовалось распечатать на бумаге “платежное поручение” и доставить его в банк. Кстати, само слово “поручение” — это от фразы “моя компания поручает вашему банку оплатить”.

Ранее в информационных системах 1С 7.0 и 1С 8.0 были такие операции, как “платежное поручение (исх.)” и “платежное поручение (вх.). В более поздних версиях 1С эти операции превратились в “поступление дс на счет” и “списание дс со счета”. Видимо, потому что уже никто не приезжает физически в банк и не приносит бумажные “платежные поручения”.

Сам бумажный документ исчез, но понятие о нем осталось в учете. До сих пор, если ожидаемый платеж “не проходит”, то продавец может попросить покупателя скинуть “платежку с отметкой банка”, которая представляет из себя электронный документ в pdf, с синим штампом, но поставленным (скорее всего) программно. Некая бутафорская “дань старине”. То есть документ на бумаге ушел в прошлое, но понятие о нем осталось.

Ну и конечно в учете банка присутствуют списки, записи, но уже не в “амбарных книгах”, а в электронных таблицах удобного для получения отчетов формата.

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

  1. списках (что учитываем)
  2. операциях (суть которых зафиксировать какое-то событие, аналоги “бумажных первичных документов” но только в системе)
  3. журналах (то как мы , в удобном для нас формате, отразим в учете операцию, аналоги “амбарных книг”)
  4. отчетах (которые легко получить из журналов, так как сконструировали их удобными для обработки и информации).

 

В архитектуре A-techs.io есть 4 типа объектов, которые соответствуют описанному выше, а именно:

  • Справочники (любые “списки”)
  • Операции (аналог “первичного документа”)
  • Журналы (аналог “амбарных книг”)
  • Отчеты (“отчеты”)

(!) И отдельно, раз мы говорим об автоматизации расчетов, то есть еще “плюс один” объект системы, который автоматизирует расчеты в системе.


 

  • Механизмом расчетов с использованием «функций и выражений» (аналог функций в Excel)

 

Итого, в A-TECHS 5 объектов. Каждый из объектов обладает своими свойствами, характеристиками и возможностями.

 


(!) То что было в Excel ячейкой с адресом (файл_лист_столбец_строка) и синтаксисом формул, это стало в A-TECHS справочником-операцией-журналом-отчетом-механизмом расчетов“.

То что было в Excel сервисом “копирования формул и автоматическим пересчетом”, вошло в A-TECHS в механизм расчетов. Дополнительно к сервисам в A-TECHS относится то, что является сервисом принятым в учетных системах: логирование и ограничение прав доступа к любой информации, история изменения, “двойная запись”, ввод на основании и прочее…

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


 

Опишем чуть более подробно.

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

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

Отчеты – это сгруппированная, адаптированная для понимания пользователем, информация.

Синтаксис функций и выражений – это набор функций, выражений, с помощью которого настраиваются все расчеты в сервисе A-TECHS. Этот инструмент чем то напоминает формулы в Excel.  Отличие от Excel в том, что синтаксис в A-TECHS направлен больше на действия с таблицами, а не с числами. На схеме потоки 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): что осталось отгрузить клиенту по заказу.

 


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


 

Схематично архитектуру  A-techs.io можно представить в виде следующей схемы.

 

______________2019-03-05___17.09.37.png

 

 


(!) Пояснения к схеме: сверху написаны объекты системы. Снизу, как можно их представить, если бы мы говорили языком Excel. Стрелочки означают нечто эфемерное, что можно назвать “информационные потоки”. Стрелка (1) — означает, что в справочниках можно настраивать ссылку друг на друга. Стрелка (2) означает, что поля в Операциях — это ссылка на справочники. Стрелка (3) — символизирует, что в операции мы настраиваем любые расчеты, используя поля и формулы (как в Excel). Стрелка (4) означает, что мы записываем операции (“первичные документы”) в журналы (“проводки в амбарных книгах”). Более подробно о журналах читайте в этой же главе чуточку ниже. Стрелка (5) означает, что мы можем получать данные из Журналов и использовать их в расчетах, это некие выражения, которые позволяют работать с таблицами, аналог формул массивов в Excel, только  более широким функционалом. Стрелка (6) означает, что при формировании отчетов мы также используем некие “функции и выражения”, например, как сводная таблица в Excel.


 

Подведем итоги главы: Мы познакомились с объектами в A-TECHS.

К этому моменту у нас есть ER-модель нашего СКВОЗНОГО ПРИМЕРА , есть алгоритм перехода от ER-модели к таблицам. Мы кратко ознакомились с объектами в системе A-TECHS. Теперь мы можем приступить к реализации СКВОЗНОГО ПРИМЕРА в системе A-TECHS.