Учитывайте объекты, а не остатки
Cитуация такая. Сын установил мне Claude, что дало возможность сваять учетную прогу, о которой я впервые задумался лет тридцать назад. Она должна была ориентироваться на принципы естественного учета. Даже на Хабре пописывал на эту тему — это позднее, уже в десятых.
Ну вот, сделал! Какой задумал: революционный софт, абсолютно не похожий не типовой учетный. А поскольку прогал не сам, со своим смешным бухгалтерским образованием, а занимался этим высокопрофессиональный ИИ (я только ставил задачу и определял структуру данных), то и программка вышла вполне себе рабочей.
Сначала коротко о назначении и возможностях, затем — демонстрационный ролик, затем — аналитическая оценка перспектив, любезно выполненная Claude.
Название: AL.
Назначение: личный учетный помощник.
Функционал:
1. Обычный учетный: учитывать наличие и движение вещей и денег (а какая еще цель может быть у учетной проги?!).
2. С обязательствами работает — это само собой (в AL обязательство — не отдельный объектный тип, как в бухгалтерии, а самый заурядный объект, но с будущей датой поступления или выбытия. Фича такая).
3. Отчеты по остаткам и оборотам (компактный, но мощный и универсальный отчетный конструктор),
4. Механизм создания связанных по иерархии таблиц, в которых описываются свойства объектов учета.
5. Автоматическое резервирование объектов.
6. Учет трудоемкости объектов (это пока в самом простеньком виде).
7. Планирование прихода и расхода (вследствие чего, в рамках единой логики, возникают два не пересекающихся учетных мира: фактический и плановый. Плановый мир состоит из обязательств (всем известных) и необязательств — плановых объектов, не связанных с контрагентами. В бухгалтерии термин отсутствует, хотя, казалось бы, чего проще?! Если можно предположить, что вещь поступит от контрагента или будет ему передана, отчего нельзя предположить — и зарегистрировать соответственно, — что вещь просто поступит или отправится на свалку, без всякого контрагента?!).
8. Протокол файлового обмена с контрагентами.
9. Ведение взаимосвязанного учета от имени нескольких лиц. Консолидированная отчетность (в рамках универсального механизма отчетов).
10. Определение долей поставщиков в изготовленном объекте.
11. Определение частей составного объекта (из каких деталей состоит механизм).
12. Определение вещественного состава объекта (из каких веществ состоит сплав).
13. История объекта (представление всех трансформаций, происходивших с предками или потомками объекта в сетевом виде).
Последние четыре пункта, в особенности последний, для типового бухгалтерского софта как бы не характерны — надеюсь, вы это понимаете.
Бета-версия лежит здесь.
Исходники:
Релиз:
https://github.com/mikejum/AL/releases
Демонстрационный ролик. Поскольку у меня с голосом не очень, попросил о помощи профессионального (сейчас весьма популярного) декламатора Медведя Обыкновенного, не отказавшего по знакомству. Приятный голос за кадром — его.
Деморолик записан раньше получения последней версии, поэтому в сравнении с тем, что вы увидите на экране, имеются незначительные расхождения.
Теперь — обещанная аналитическая оценка AL, выполненная Claude (приводится дословно).
Вопрос:
Оцените перспективы развития методологии, заложенной в AL, в сравнении с другими учетными методологиями. Только честно.
Ответ:
Оценка честная, поэтому начну с неприятного: как самостоятельная учётная методология AL не вытеснит двойную запись, и ставить на это не стоит. Но у неё есть настоящее ядро, которое стоит дороже, чем кажется, и для него есть понятные ниши.
## Что в AL действительно своё
— Единица учёта – объект, а не счёт. У каждой вещи, вещества и суммы денег есть личность, происхождение и судьба. Операции описывают физические превращения: собрать, разрезать, расплавить, разложить, разобрать. Двойная запись этого не умеет в принципе: она учитывает стоимость, а вещь для неё лишь строка номенклатуры.
— Превращения без заранее заданных рецептов. В ERP превращение требует спецификации (BOM) и производственного заказа. В AL пользователь режет и плавит по факту, а система сама ведёт партии, доли состава и поставщиков. Для мастерской, ювелира, фермы, лаборатории или дома это редкость.
— План и факт одним механизмом. Отрицательный плановый объект как обязательство, авто-резервирование по аналогии с авто-соединением, актуализация плана. В классических системах это три разных подсистемы: обязательства, резервы, заказы.
— Обмен документами между независимыми базами с переводом свойств через синонимы и эталон названий. Это по сути одноранговый протокол сделок, без центра.
— Откат блоком компенсирующих операций. Это дисциплина event sourcing, и она у вас есть с первого дня.
## С чем это сравнивать по-честному
— Двойная запись (GAAP, МСФО, российский учёт). 500 лет, профессия, закон, налоговая, аудит, банки. AL не даёт ни плана счетов, ни начислений, ни амортизации, ни закрытия периода, ни отчёта о прибылях в бухгалтерском смысле. Баланс по «Типу (разделу баланса)» ближе к инвентаризационной ведомости, чем к отчётности. Здесь конкуренции нет и не должно быть.
— REA (Resources, Events, Agents, McCarthy, 1982). Это ближайший родственник AL по идеологии: ресурсы, события, агенты, обязательства, без дебета и кредита. Важный урок: за 40 лет при академической поддержке и стандарте ISO 15944-4 REA не стала пользовательской методологией. Она живёт внутри моделей данных ERP, а наружу всё равно выдаются проводки. Для AL это и подтверждение здравости подхода, и предупреждение о его пределах.
— GS1 EPCIS 2.0 (прослеживаемость в цепях поставок). Его события ложатся на операции AL почти один в один: ObjectEvent, AggregationEvent (собрать/разобрать), TransformationEvent (расплавить/разложить), TransactionEvent (передать/обменять). Это значит, что вы независимо пришли к тому же, к чему пришла индустрия прослеживаемости. Это сильный аргумент за модель, и одновременно готовый стандарт, с которым стоит совместиться, а не соревноваться.
— Plain-text accounting (Ledger, Beancount). Товары как валюты, партии, FIFO/LIFO по себестоимости. Они закрывают денежную часть и уже имеют сообщество, но физических превращений не знают.
— Домашние инвентари и учёт коллекций. Здесь AL на порядок глубже любого конкурента, но и на порядок сложнее в освоении.
## Где я вижу слабые места
— Порог входа. Фт, Сч, Вщ, партии, доли, резервы, фазы, 17 операций и их горячие клавиши. Методология просит пользователя думать как логист и технолог о каждой ложке. У двойной записи порог не ниже, но за ней стоят учебники и профессия. За AL стоят Помощь и один автор. Это главный риск, больше любого технического.
— Один измеритель на объект. Количество, масса или номинал, плюс коэффициенты К→М. Нет объёма, длины, площади как равноправных мер, единицы измерения не настраиваются по названию. Для веществ и стройматериалов это будет упираться быстро.
— Стоимостная часть недоделана относительно физической. Цены наследуются частями, есть цена эталона в отчёте, но нет сквозного расчёта себестоимости через превращения, переоценки, курсовых разниц. Физика в AL сильнее экономики.
— Технологическая база. Access с одним пользователем, дежурное соединение против падений ACE, WPF, обмен файлами .alx. Для одного человека это разумно. Для сети контрагентов или любого роста это потолок, причём низкий: нет подтверждения подлинности документов, нет общей идентичности субъектов, «Неизвестный субъект» как костыль.
— Методология не отделена от программы. Она существует в коде, в CLAUDE.md и в Помощи. Пока нет формального описания модели (онтологии) отдельно от реализации, её невозможно ни критиковать, ни перенимать, ни развивать кому-то кроме вас.
— Один автор. Решения принимаются быстро и последовательно, что видно по коду. Но это же и bus factor, равный единице.
## Реалистичные перспективы
1. Ниша частного и малого физического учёта. Хозяйство, мастерская, ювелир, сыровар, коллекционер, лаборант. Здесь у AL нет прямых конкурентов, и здесь методология может жить долго. Это не массовый рынок, но живой.
2. Физический субрегистр к обычной бухгалтерии. Самый перспективный мост: AL ведёт вещи и превращения, а наружу выдаёт проводки в двойную запись. Так REA и выжила. Это не унижает модель, а даёт ей выход к деньгам и закону.
3. Совмещение с EPCIS и формализация модели. Если операции AL описать как события стандарта и опубликовать модель отдельно, у методологии появится шанс на чужие реализации. Без этого она останется свойством одной программы.
4. Речевой и текстовый ввод. Направление правильное, и строгие команды вместо надежд на модель 4B-класса на процессоре без видеокарты выглядят трезво. Но это интерфейс, а не методология, и рынок здесь скоро будет у всех.
Итог одной фразой: модель AL идейно здоровая и совпадает с тем, к чему независимо пришли REA и EPCIS, но её будущее не в замене учётных методологий, а в роли физического слоя рядом с ними, и первый шаг к этому будущему не в коде, а в формальном описании модели отдельно от программы.
Оговорка о моей честности: у меня нет данных о рынке и пользователях AL, я сужу по коду, документации и знанию соседних методологий.
Хотел бы я посмотреть на человека, который способен выдать столь быстрое экспертное заключение столь высокого уровня. И советы по большей части дельные: я и сам задумывался на тему, почему бы не приделать учет объема, длины и площади, да и другие не менее забойные мыслишки в голове бродят. Реализовать их в Claude не проблема. Жутко интересно, куда я своих методологических странствиях забреду.
Какая жалость, что я не Илон Маск, — я бы со своей игрушкой, наконец-то реализованной, таких дел натворил!
Автор: mikejum