Cитуация такая. Сын установил мне Claude, что дало возможность сваять учетную прогу, о которой я впервые задумался лет тридцать назад. Она должна была ориентироваться на принципы естественного учета. Даже на Хабре пописывал на эту тему — это позднее, уже в десятых.
Ну вот, сделал! Какой задумал: революционный софт, абсолютно не похожий не типовой учетный. А поскольку прогал не сам, со своим смешным бухгалтерским образованием, а занимался этим высокопрофессиональный ИИ (я только ставил задачу и определял структуру данных), то и программка вышла вполне себе рабочей.
Сначала коротко о назначении и возможностях, затем — демонстрационный ролик, затем — аналитическая оценка перспектив, любезно выполненная Claude.
Название: AL.
Назначение: личный учетный помощник.
Функционал:
Обычный учетный: учитывать наличие и движение вещей и денег (а какая еще цель может быть у учетной проги?!).
С обязательствами работает — это само собой (в AL обязательство — не отдельный объектный тип, как в бухгалтерии, а самый заурядный объект, но с будущей датой поступления или выбытия. Фича такая).
Отчеты по остаткам и оборотам (компактный, но мощный и универсальный отчетный конструктор),
Механизм создания связанных по иерархии таблиц, в которых описываются свойства объектов учета.
Автоматическое резервирование объектов.
Учет трудоемкости объектов (это пока в самом простеньком виде).
Планирование прихода и расхода (вследствие чего, в рамках единой логики, возникают два не пересекающихся учетных мира: фактический и плановый. Плановый мир состоит из обязательств (всем известных) и необязательств — плановых объектов, не связанных с контрагентами. В бухгалтерии термин отсутствует, хотя, казалось бы, чего проще?! Если можно предположить, что вещь поступит от контрагента или будет ему передана, отчего нельзя предположить — и зарегистрировать соответственно, — что вещь просто поступит или отправится на свалку, без всякого контрагента?!).
Протокол файлового обмена с контрагентами.
Ведение взаимосвязанного учета от имени нескольких лиц. Консолидированная отчетность (в рамках универсального механизма отчетов).
Определение долей поставщиков в изготовленном объекте.
Определение частей составного объекта (из каких деталей состоит механизм).
Определение вещественного состава объекта (из каких веществ состоит сплав).
История объекта (представление всех трансформаций, происходивших с предками или потомками объекта в сетевом виде).
Последние четыре пункта, в особенности последний, для типового бухгалтерского софта как бы не характерны — надеюсь, вы это понимаете.
Бета‑версия лежит здесь.
Демонстрационный ролик. Поскольку у меня с голосом не очень, попросил о помощи профессионального (сейчас весьма популярного) декламатора Медведя Обыкновенного, не отказавшего по знакомству. Приятный голос за кадром — его.
Деморолик записан раньше получения последней версии, поэтому в сравнении с тем, что вы увидите на экране, имеются незначительные расхождения.
Теперь — обещанная аналитическая оценка 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, равный единице.
## Реалистичные перспективы
Ниша частного и малого физического учёта. Хозяйство, мастерская, ювелир, сыровар, коллекционер, лаборант. Здесь у AL нет прямых конкурентов, и здесь методология может жить долго. Это не массовый рынок, но живой.
Физический субрегистр к обычной бухгалтерии. Самый перспективный мост: AL ведёт вещи и превращения, а наружу выдаёт проводки в двойную запись. Так REA и выжила. Это не унижает модель, а даёт ей выход к деньгам и закону.
Совмещение с EPCIS и формализация модели. Если операции AL описать как события стандарта и опубликовать модель отдельно, у методологии появится шанс на чужие реализации. Без этого она останется свойством одной программы.
Речевой и текстовый ввод. Направление правильное, и строгие команды вместо надежд на модель 4B‑класса на процессоре без видеокарты выглядят трезво. Но это интерфейс, а не методология, и рынок здесь скоро будет у всех.
Итог одной фразой: модель AL идейно здоровая и совпадает с тем, к чему независимо пришли REA и EPCIS, но её будущее не в замене учётных методологий, а в роли физического слоя рядом с ними, и первый шаг к этому будущему не в коде, а в формальном описании модели отдельно от программы.
Оговорка о моей честности: у меня нет данных о рынке и пользователях AL, я сужу по коду, документации и знанию соседних методологий.
Хотел бы я посмотреть на человека, который способен выдать столь быстрое экспертное заключение столь высокого уровня. И советы по большей части дельные: я и сам задумывался на тему, почему бы не приделать учет объема, длины и площади, да и другие не менее забойные мыслишки в голове бродят. Реализовать их в Claude не проблема. Жутко интересно, куда я своих методологических странствиях забреду.
Какая жалость, что я не Илон Маск, — я бы со своей игрушкой, наконец‑то реализованной, таких дел натворил!
