AccountLogic 2.0: доведенная до ума, но не до окончания

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

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

    На сегодняшний день «ЭкаунтоЛогика» (новое обрусевшее название «Учетная Логика») позволяет – по крайней мере, должна позволять согласно спецификации – достаточно многое.

    Возможности Учетной Логики
    √ Создавать и редактировать учетные объекты в соответствии с их вещной природой.
    √ Отслеживать не только их прошлые, но и будущие изменения (обязательства) с точностью до секунды.
    √ Оценивать учетные объекты по произвольному числу измерителей.
    √ Интегрировать в объекты и действия готовые справочники.
    √ Согласованно передавать объекты между пользовательскими базами.
    √ Автоматически выполнять повторяющиеся действия.
    √ Отслеживать материальные связи между объектами.
    √ Привязывать файлы к отдельным объектам, действиям или папкам.
    √ Вести плановые, параллельные основным, базы данных.
    √ Составлять иерархические отчеты (отчетные папки), в том числе с учетом курсовых разниц и сравнительно с плановыми данными.
    √ Просматривать данные в табличном режиме и в режиме иконок.


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


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

    I.
    Сервисные функции: архивация, паролирование, локализация (английский – машинный перевод, откорректированный в меру моих мизерных толмаческих навыков).



    Все стандартно, не представляет малейшего методологического интереса.

    II.
    Данные в базе разделены на две части: фактические (основные) и плановые (дополнительные, учитываемые параллельно основным для сравнения с ними). Типовая возможность, не склоняющая к разнообразию.

    В отчетных папках предусмотрено как отдельное, так и совместное представление фактических и плановых данных.





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

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



    Соотнести файл можно с одним из следующих элементов:
    1. вещью (что изображено на картинке),
    2. действием,
    3. папкой.

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

    Полезный сервис, не более.

    IV.
    Перехожу непосредственно к учетным нововведениям, а именно к редактированию вещей.

    При рассмотрении версии 1.0 мне попеняли – не в бровь, а в глаз. Претензия была такой: «В комнате находится несколько вещей. Допустим, я переместил все вещи на балкон, тем самым изменил свойство данных вещей. Было [местоположение] = «комната», стало [местоположение] = «балкон». И что же, я должен поодиночке изменять свойство у каждой вещи? Неужели нельзя сразу?».

    Теперь можно. Выделяем нужные вещи и изменяем свойство на требуемое.



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

    Идеология программы максимально приближена к реальности, поэтому допускается работать с вещами в естественной последовательности. Если у вас имеется 100 руб., и вы передаете 10 из них контрагенту, невозможно просто передать их, ведь до поры до времени 10 руб. составляют часть 100 руб. Следуя экаунтологическим постулатам, сначала придется разделить общую сумму на 90 руб. и 10 руб., затем получивший цельный объект можно передать по назначению. Вместо понятной одной передачи возникают две операции: вроде бы излишнего разделения и передачи. Это, несмотря на безукоризненное теоретическое обоснование, нервирует, посему написана функция автоматического разделения вещей на части.

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



    «Учетная Логика» сама отделит указанную часть от целого объекта и запишет данное действие в качестве предваряющего основное.

    Итогом станет запись двух действий, по сути, выполненных совместно. Нервничать по поводу «излишней» операции не придется.



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

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

    V.
    Далее, увеличена временнАя точность программы.

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

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



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

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

    Проведем несложный эксперимент.

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



    Зайдем в «Настройки» и установим учет с точностью до секунд.

    Откроем окно добавления, укажем название вещи и – главное – установим время совершения операции секунд на 20 больше текущего момента (момента регистрации). Не забудем указать вероятность менее 100 %.



    Добавим вещь. В рабочем окне (для наглядности установим режим иконок) ее пока не видно: правильно, ведь вещь поступит через несколько секунд.



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



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

    Согласно экаунтологическим воззрениям, обязательство – будущая вещь, зарегистрированная ранее того. Если вам точно известно: через час на склад поступит вещь, которую вы по поступлении зарегистрируете, – это будущая вещь, вы можете выполнить запись заранее, будущим временем. Но если вы СЕЙЧАС регистрируете будущее поступление вещи – это уже обязательство).

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

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

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

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



    Ничего примечательно ни с практической, ни с теоретической точек зрения.

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

    VII.
    Приделан учет курсовых разниц.

    Допустим, вещь стоимостью 100 руб. поступила 1 марта (курс 50 руб. за 1 доллар), а выбыла 30 марта (курс 75 рублей за 1 доллар). Тогда стоимость поступления вещи составляет 2 доллара, а стоимость выбытия 1,33 доллара. Разница между ними и называется курсовой.

    Зададим необходимые параметры, для чего нам придется подключить заранее приготовленную базу Access. Иначе курсовые разницы не подсчитать. Как их подсчитать, если вести учет можно одновременно в рублях, долларах, евро или любых других измерителях – основной валюты нет, все они основные? Но если взять базу с курсами валют, тогда установленный в настройках измеритель автоматически становится основной валютой, дополнительной считается валюта, повременное соотношение которой указано в базе.



    В результате в отчетных папках возникнет дополнительный столбец.



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

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

    Допустим, учет ведется в рублях. В соответствии с правилами бухгалтерского учета никакой курсовой разницы здесь нет. Но в реальной экономике доллары-то есть, они обращаются – следовательно, разница может быть исчислена, ведь стоимости покупки и продажи, реально проводимые в рублях, всегда могут быть пересчитаны в доллары. В этом случае стоимости покупки и продажи не совпадут, появится разница – курсовая, а какая еще!

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

    Скажем, поступила вещь стоимостью 100 руб., курс на этот момент составлял 50 руб. за доллар. Через некоторое время вещь (стоимостью те же самые 100 руб., вестимо) выбыла, курс доллара составлял уже 55 руб. Значит, курсовая разница между данными датами (то есть на дату выбытия) составила… Считайте сами: поступила вещь стоимостью 2 доллара, выбыла та же самая вещь стоимостью около 1,82 долларов. Курсовая разница составит в таком случае 18 центов в сторону уменьшения долларовой стоимости за период. «Учетная Логика» способна зафиксировать данный факт (если, конечно, я не напутал с алгоритмами, которые из-за множества настроек весьма громоздкие).

    VIII.
    Очень практичная функция – подключение справочников.

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

    После некоторых колебаний я выбрал вариант с подключением сторонних баз данных. Предполагается, что пользователь ведет справочники штатными средствами Access, а в «Учетную Логику» они импортируются в готовом виде, при помощи соответствующего диалогового окна.



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

    На этом перечисление новых фич закончено. Кое-какие функции, небезынтересные и практически написанные, были выкинуты по той причине, что я с ужасом осознал: пользоваться ими на данном этапе исторического развития нельзя, слишком неудобно. Поэтому можно сказать: «Учетная Логика» 2.0 уперлась в потолок методологических возможностей.

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

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

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

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

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

    Для фиксации финансового результата (прибыли или убытка) продавец переоценивает вещь по продажной стоимости, к примеру: стоила вещь столько-то (себестоимость), стала стоить столько-то (продажная цена). Разница между данными величинами представляет собой прибыль или убыток. Чтобы отделить финансовый результат от прочих оборотов, создаем новое свойство (как его назвать, понятное дело, все равно: СтатьяЗатрат, ДоходыРасходы или как-то иначе, в примере намеренно использованы разные названия) и в качестве значения указываем… положим, так и указываем: финансовый результат.

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

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



    Здесь показано состояние по контракту № 5: прибыль составила 88 тыс. руб., взаиморасчеты на установленный момент по нулям (оборот 200 тыс. руб.). А если бы и были не по нулям, приведенные показатели позволяют, посредством простого сравнения, рассчитать прибыль по любой методе (имеются в виду такие известные бухгалтерские заморочки, как кассовый метод и метод начисления).

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

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

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

    Скачать «Учетную Логику» 2.0 можно здесь. Системные требования не изменились: необходим 32-разрядный Microsoft Office. При 64-разрядной Windows требуется установить утилиту Microsoft Access Database Engine 2010 (32-разрядную). Работа при 64-разрядных Windows и Microsoft Office, насколько я понимаю, невозможна: что с этой напастью делать, ума не приложу.

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

    Мой программистский стаж чуть более 1 года, сами сообразите, что это значит. (Для несообразительных поясняю: множество ошибок первой глючной версии я поисправлял, но это не значит, что удалось не насажать новых). Вместе с тем мой стаж как методолога – четверть века: иначе говоря, я отвечаю не столько за программный код, сколько за учетную методологию, в нем претворенную.

    Себя в преимуществах экаунтологической методы я убедил основательно, удастся ли убедить большинство, не суть важно. Кто захочет, услышит.
    Support the author
    Share post

    Comments 0

    Only users with full accounts can post comments. Log in, please.