15. Метод двойной записи, C точки зрения таблиц (The Table Perspective)
← Вернуться на главную
← Назад: 14. Простой текстовый учет (Plain Text Accounting)
Почти всегда вопросы, задаваемые пользователями, о том, как рассчитать или отследить то или иное значение, можно легко решить, просто думая о данных, как о длинном списке строк, некоторые из которых нужно отфильтровать и сгруппировать. Если учесть, что все, что мы в итоге делаем - это получаем "суммы" этих проводок, а атрибуты операций и проводок - это то, что позволяет нам фильтровать подмножества проводок, то это всегда становится очень просто. Почти во всех случаях ответ заключается в том, чтобы найти какой-то способ разделить проводки для их выделения, например, по имени учетной записи, прикрепив какой-нибудь тег, используя какие-нибудь метаданные и т.д. Может быть интересно рассмотреть, как эти данные могут быть представлены в виде таблицы.
Представьте, что у вас есть две таблицы: таблица, содержащая поля каждой транзакции, такие как дата и описание, и таблица для полей каждой проводки, таких как счет, сумма и валюта, а также ссылка на ее родительскую транзакцию. Самый простой способ представления данных - объединить эти две таблицы, реплицируя значения родительской транзакции по каждой из проводок.
Например, этот вход Beancount:
2016-12-04 * "Christmas gift"
Liabilities:CreditCard -153.45 USD
Expenses:Gifts
2016-12-06 * "Biang!" "Dinner"
Liabilities:CreditCard -47.23 USD
Expenses:Restaurants
2016-12-07 * "Pouring Ribbons" "Drinks with friends"
Assets:Cash -25.00 USD
Expenses:Tips 4.00 USD
Expenses:Alcohol
Может быть отображен в виде таблицы, как эта:
Обратите внимание, как значения полей транзакции реплицируются для каждого сообщения. Это похоже на обычную операцию присоединения базы данных. Поля для проводок начинаются со столбца "Счет". (Также обратите внимание, что эта таблица примера упрощена; на практике существует гораздо больше полей).
Если бы у вас была такая же объединенная таблица, вы могли бы отфильтровать ее и просуммировать суммы для произвольных групп проводок. Это именно то, что позволяет сделать инструмент bean-query tool: Вы можете выполнить SQL-запрос к данным, эквивалентным этой таблице в памяти, и к значениям списка, подобным этому:
SELECT date, payee, number WHERE account = "Liabilities:CreditCard";
Или подытожить позиции:
SELECT account, sum(position) GROUP BY account;
Эта простая последняя команда генерирует отчет о пробном балансе. Обратите внимание, что табличное представление по своей природе не ограничивает число проводок в сумме до нуля. Если ваш критерий выбора строк (в пункте WHERE) всегда выбирает все записи по каждой из совпадающих транзакций, вам гарантируется, что итоговая сумма всех записей равна нулю. Если нет, то сумма может быть любой другой. Просто не забывайте об этом.
Если вы знакомы с базами данных SQL, вы можете спросить, почему Beancount просто не обрабатывает свои данные для того, чтобы заполнить существующую систему баз данных, чтобы затем пользователь мог воспользоваться инструментами этой базы данных.
Для этого есть две основные причины:
-
Отчетность об операциях (Reporting Operations)
Для составления отчетов о прибылях и убытках (income statement) и бухгалтерских балансов (balance sheet) необходимо предварительно обработать перечень транзакций с использованием очистки (clear), открытых (open) и закрытых (close) операций, описанных выше. Эти операции не тривиальны для реализации в запросах к базе данных, зависят только от отчета и в идеале не нуждаются в изменении вводимых данных. Нужно загрузить данные для отправки в память, а затем запустить какой-нибудь код. Мы уже это делаем, разбирая входной файл; шаг БД будет лишним. -
Суммарные позиции(Aggregating Positions)
Хотя мы пока не обсуждали это в данном документе, содержание счетов может содержать различные виды товаров, а также позиции с привязкой к себестоимости (cost basis). Способ, которым эти позиции агрегируются вместе, требует реализации пользовательского типа данных, потому что он подчиняется некоторым правилам о том, как позиции могут аннулировать друг друга (смотрите раздел Как работает инвентаризация). Было бы очень сложно построить эти операции с помощью базы данных SQL, выходя за рамки использования только одной валюты и игнорируя стоимостную основу.
Вот почему Beancount предоставляет пользовательский инструмент для непосредственной обработки и запроса данных: Он предоставляет собственную реализацию SQL-клиента, который позволяет указывать даты открытия и закрытия, а также использует пользовательскую структуру данных «Инвентаризация (Inventory)» для создания сумм позиций проводок. Этот инструмент поддерживает колонки основных типов Beancount: Amount, Position и Inventory Objects.
В любом случае, если вы не уверены, Beancount предоставляет инструмент для экспорта своего содержимого в обычную систему баз данных SQL.