Декларирайте роли на паричните потоци в ledger-а си: Един ред метаданни заменя предположенията

Всеки отчет за паричните потоци почива на едно тихо решение, взето веднъж за всяка сметка: тази сметка част от паричните средства, които обяснявате, или операционна, инвестиционна или финансова дейност? Вземете правилното решение и отчетът ви казва къде всъщност отиват парите ви. Вземете грешното и отчетът убедително ви подвежда.

Досега отчетът за паричните потоци в Beancount.io вземаше това решение вместо вас чрез евристики — основния тип на сметката, плюс предположение по име кои активи се броят за пари. За повечето ledger-и предположението беше вярно през повечето време и мълчаливо грешно през останалото. Брокерска сметка, наименувана по грешен начин, попадаше в грешната секция. Паричен фонд на паричния пазар, който на практика е пари, стоеше в Инвестиционни дейности, защото името му не го подсказваше.

От днес можете да направите класификацията изрична. Един ред стандартни beancount метаданни върху open директивата на сметката:

2000-01-01 open Assets:US:Brokerage
  cash-flow-role: "investing"
 
2000-01-01 open Assets:US:Marcus:Savings
  cash-flow-role: "cash"

Един ключ, четири стойности — cash, operating, investing, financing — и това е цялата конфигурация. Няма страница с настройки, няма JSON файл, няма диалогов прозорец за опции за отделния отчет. Следващият път, когато отчетът за паричните потоци се зареди, потоците на брокерската сметка се появяват под Инвестиционни дейности, спестовната сметка се присъединява към паричните средства, чиято промяна отчетът обяснява, а всяка друга сметка продължава да работи точно както преди.

Какво означава всяка роля​

Отчетът за паричните потоци сортира всяка сметка в една от две функции и cash-flow-role отговаря на въпроса с една дума:

• "cash" — сметката принадлежи към паричните средства и еквиваленти. Паричните сметки никога не се появяват като редове в отчета; отчетът обяснява промяната в общия им баланс, а преводите между две парични сметки се компенсират взаимно — така, както преместването на пари от разплащателна в спестовна сметка би трябвало да работи.
• "operating" / "investing" / "financing" — сметката не е пари и промяната ѝ за периода се появява като ред в съответната секция на дейностите.

По подразбиране отчетът третира активи, чиито имена съдържат Cash, Checking, Savings или Bank, като парични еквиваленти. Декларирането на роля отменя това и в двете посоки. cash-flow-role: "cash" включва сметка, която правилото по име пропуска — например паричен фонд на паричния пазар или портфейл със стабилни монети. А cash-flow-role: "investing" върху Assets:US:Bank:CD прави две неща с един ред: изключва депозитния сертификат от паричните средства и го класифицира като инвестиция, дори името му да отговаряше на правилото за пари.

Умишлено използвахме един ключ вместо два. „Тази сметка пари ли е?" и „към коя секция на дейностите принадлежи?" никога не са били независими въпроси — една сметка или е част от паричните средства, или принадлежи към точно една секция на дейностите. Два ключа биха позволили безсмислени състояния, като парична сметка с роля на дейност. Един ключ прави невалидните състояния непредставими, а цялата спецификация се побира в една публикация в Twitter.

Класификацията, която декларирате, е класификацията, която всеки изглед използва. Диаграмата „По дейности“ подрежда операционните, инвестиционните и финансовите потоци по месеци; преместете ролята на дадена сметка и нейните потоци се преместват в правилния слой на диаграмата, в правилната секция на отчета и в правилния ред на експорта — всичко това наведнъж.

Декларираното побеждава предположеното — и отчетът си показва работата​

Класификацията вече се разрешава в строг ред: първо вашите метаданни, второ вградената евристика. И отчетът е честен за това, което е направил. Отчетът за паричните потоци завършва с панел „Парични средства и еквиваленти в този отчет“, който изброява точно кои сметки е третирал като пари при изготвянето на числата, и след това ги съгласува: парични средства в началото на периода, парични средства в края на периода и нетната промяна, която секциите на дейностите обясняват.

Отчетът също така прави разлика между класификации, които вие сте декларирали, и такива, които са изведени. Тази разлика се пренася и в експортите за CSV и Markdown: отчет, изграден изцяло от декларирани роли, вече не носи реда „класификацията е изведена“, защото в този момент класификацията не е извод — тя е част от книгите ви.

Грешките се обработват така, както инструментът за plain text трябва да ги обработва. cash-flow-role: "invsting" не се приема мълчаливо и не се игнорира мълчаливо: сметката се връща към евристиката по подразбиране, а панелът със състоянието я отбелязва с флаг — „неизвестна стойност за cash-flow-role, използвана е стойността по подразбиране“ — така че грешката е видима там, където я търсите, а не погребана в логове.

Ако не промените нищо, нищо не се променя​

Неанотираните сметки използват същите публикувани стойности по подразбиране като преди: Приходите и Разходите се отнасят към операционната дейност, непаричните Активи — към инвестиционната, Пасивите и Собственият капитал — към финансовата, а паричните еквиваленти, съвпадащи по име, образуват паричната маса. Съществуващият ledger изглежда идентично преди и след този ъпдейт. Повечето потребители ще анотират шепа сметки — тези, при които стойността по подразбиране е грешна — и няма да мислят за останалите.

Преносимостта също не е засегната. Метаданните върху open директивите са основен синтаксис на beancount, разбираем от всеки инструмент за v2/v3 и игнориран от всичко, което не търси точно този ключ. bean-check преминава, Fava свива рамене, а ledger-ът ви остава напълно функционален извън Beancount.io.

Всеки изглед на парите ви е съгласен с всеки друг​

Единният споделен резолвър произвежда крайната роля за всяка сметка и всеки потребител на данните чете от него:

• Отчетът за паричните потоци изгражда секциите на дейностите и обобщаващия ред — нетната промяна в паричните средства и еквиваленти — от разрешените роли.
• Експортите за CSV, Markdown и печат носят същите числа, като оповестяването за изведена класификация се появява само там, където наистина е използвана евристика.
• Sankey диаграмата в обзора чете същите декларации, така че сметка, която сте отбелязали като пари, престава да се появява като възел на поток, а декларираните от вас роли на дейности се зачитат за сметки извън Приходите/Разходите.
• Панелът със състоянието на сметката престава да я показва като „некласифициран актив“.

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

Защо ledger-ът, а не страница с настройки​

Това е частта от ъпдейта, за която сме най-убедени. Обмислихме потребителски интерфейс за настройки и го отхвърлихме по три причини:

1. Ledger-ът е източникът на истината. Класификация, която живее където и да е другаде, може да противоречи на книгите, които описва. Класификация, която живее върху open директивата, пътува със сметката — през преименувания, през премествания на хранилището, през всеки клиент, който чете файла.
2. Plain text може да се дифва, търси и ревюира. Ако държите ledger-а си в git — а ако използвате Beancount.io, го правите — правилото за класификация вече е нещо, което можете да grep-вате, diff-вате и blame-вате, и нещо, което ревюиращ може да види в pull request. Страница с настройки не е нито едно от тези неща.
3. Работи офлайн и навсякъде. Всеки редактор може да декларира роля. Всеки бъдещ клиент, който чете ledger-а, получава класификацията безплатно, без никакви настройки за синхронизиране между клиенти.

По същата причина класификациите умишлено не са обвързани с дати. Метаданните описват природата на сметката, която рядко се променя; когато се промени, редактирате open директивата и вашата git история записва какво се е променило и кога. Тази история е одитната следа.

Изпробвайте го върху вашия ledger​

Функцията вече се разпространява към всички ledger-и. Декларирането на роля изисква само текстов редактор:

1. Отворете файла, където се намира open директивата на сметката.
2. Добавете cash-flow-role: "cash" (или "operating", "investing", "financing") като метаданни на нов indent-иран ред под нея.
3. Презаредете отчета за паричните потоци. Вашата декларация веднага побеждава евристиката.

Започнете със сметките, при които предположението по подразбиране е грешно — депозитният сертификат, който всъщност не е пари, паричният фонд на паричния пазар, който наистина е, брокерската сметка, която искате чисто под Инвестиционни дейности. Оставете останалите на мира. Пълната спецификация — приети стойности, приоритет, класификации по подразбиране и как се обработват невалидните стойности — се намира в референцията за Роли на паричните потоци.

Отчетът за паричните потоци е част от всеки ledger в Beancount.io, заедно с отчета за приходите и разходите и баланса. Ако наваксвате с другите неща, които излязоха това лято — по-умни импорти, AI асистент с възможности за действие и изцяло обновено мобилно приложение — бележките към версия 3.6 описват останалото.

Вашите книги вече знаеха кои сметки са инвестиции и кои са ежедневни разходи. Сега отчетът за паричните потоци знае същото.