hrj / abandon Goto Github PK

The idea is to capture different transactions based on a defined condition. This could be useful, for example, when recording depreciation under two acts (company act or income tax act).

Two things are required:

• A way to define a boolean property for a report
• A way to define transactions based on a condition

It should be possible to assign aliases to account names.

Configuration

accounts += {
  name = "Assets:Current:ICICI_Bank"
  alias = "ibank"
}
accounts += {
  name = "Assets:Current:Cash"
  alias = "cash"
}

Example useage

2013/10/1
  ibank    -1000
  cash

will be equivalent to

2013/10/1
  Assets:Current:ICICI_Bank    -1000
  Assets:Current:Cash

Reports

In the output, the original account name will be shown.
The alias is only applied in the input stage.

Would be cool to have a single-line compact notation, such as:

. 2014/Jan/1  cash  2000   ; withdrawl

The dot at the beginning flags the special syntax. Some other character could also be used.

This would work only when there is a default account in scope. Something like:

{
def defaultAccount = "bank" 

. 2014/Jan/1  cash    2000   ; withdrawl
. 2014/Feb/2  rent    3000   ; paid rent for Jan
}

This notation can cover about 90 % of transactions

FastParse claims to be better than everything out there. Gotta try it sometime. Speed is not a priority for us, just a good-to-have.

It would be convenient if abandon scripts could try to use java from JAVA_HOME instead of PATH.

Given a.ledger:

2013/Jan/1
  e:a     100
  i

2013/Jan/1
  e:b     100
  i

2013/Jan/1
  e:c     100
  i

2013/Jan/1
  e:c     -100
  i2

And a.conf:

inputs += a.ledger

reports += {
  title = "All"
  type = balance
}

abandon_cli.sh -c accounts.conf gives:

All
───

   200.00   e      
   100.00    ├╴a   
   100.00    ├╴b   
  -300.00   i      
   100.00   i2     
───────────────────────────────
     0.00           0.00 = Zero

The ASCII art is slightly broken for e:b. It should have an elbow joint rather than a T-Joint.

Ability to define some accounts as locked.
It should not be possible to directly transact on these accounts.

For example, if Income is locked, it shouldn't be possible to add transaction directly on Income, but transacting on a child account of Income should be allowed (if the child is unlocked).

Configuration

Regex based matching. Example:

locked += [Income, "^Capital.*"]

Use-cases

• Force the use of sub-categories for an account.
• Avoid mistakenly making transactions on rarely used accounts

https://github.com/ochafik/Scalaxy

This project looks promising:
https://github.com/lihaoyi/utest

Assigned to @sheetalk

Leaving transaction amounts empty is not generally possible for more than one account.

However, for certain cases, it may be allowed. For example, when closing nominal accounts at the end of the year, it would be convenient to do this:

2013/3/31
  Capital:Surplus                        1000
  Expense
  Income

Instead of:

2013/3/31
  Capital:Surplus                         1000
  Expense                                +1000
  Income                                 -2000

For background information, please see #78 and especially #78 (comment).

For example, there should be AND, OR and maybe also NOT. For backwards compatibility, expression filter should start with parenthesis (or some other way it should be possible to support plain filter syntax with implied AND).

For example:
((begin=2016-01-01 AND end=2016-03-01) OR account = .*:Bank:.*)

While parsing keep track location of a transaction in source.
When showing a report in GUI, make it possible to see the source file for a displayed transaction.

A destination in a closure shouldn't be present in the source list.

This should throw an Error, and there should be a unit-test for this.

Assigning to @sheetalk

Often, the input .ledger files are meant for a specific year. It would be nice to validate the date of the transaction, to ensure that the date lies within the year (or quarter, month, whatever).

Many UI based accounting packages do this naturally but since abandon has a text-based input it is easy to make mistakes in the date field. This is especially a problem in countries where the financial year is not aligned with the calendar year. In India, for example, financial year begins in March, and hence dates can get messed up while yanking and pasting.

Plan:

• Have a config option for specifying the valid date range. (Ref. eodConstraints)
• We could add a directive to .ledger file to forcefully accept a particular date. Usually, opening balances are posted on the day before the financial year. Since this is an exceptional transaction and we don't want other transactions to be posted on that date, a "force accept date" directive would be useful. The config file constraint can then be set to allow only dates for the financial year.

This is useful to get previous years closing balances as opening balances for next year.

This will be equivalent to the equity report in ledger-cli

Please see #80 and #80 (comment) for background information.

There should be in-memory filesystem for test-runner output files, because currently multiple runs could mask failures with spurious, stale output files.

Code in question is currently in cli/src/test/../CliTestRunner.scala.

Makes it possible to use abandon in shell scripts

IIRC, the code refers to transactions and posts interchangeably.

Per convention, we should change it such that:

• Post refers to a single change in a single account
• Transaction refers to a set of balanced posts

For example, in:

2015/Jan/15
    abc           -100
    xyz

there should be two posts:

• abc -100
• xyz +100

and a transaction that comprises of the above two posts.

Especially register report should have different groupBy selectors, so you can group transactions either by year, month or day. Also grouping by week and weekday should be supported.

Keyword for this could groupBy for both command line and conf-file, and possible selectors year, month, day, week and weekday.

This needs PR(#84) or similar functionality merged.

Hi, guys.
How should I use abandon from my won scala code? Any recommendations?

I see that it reads data from a file - is there a way to feed it just a string?
Similarly for commands, can they be issued at the scala level? I.e. register, balance etc...

This fails to parse:

Expenses:Personal:Furniture         -(380+450+5)

config-annotation provides macros for easier reading of config files.

2014/march/31

is not accepted, but

2014/March/31

works.

AccountName                 0.00

throws a parse error.

2013/apr/6

throws an exception.

• Track location within input file during parsing. Try to track both start and end locations.
• Use this information while displaying errors.

There will be duplicated xml output inside output-file, when there is also stdout (e.g. "-") defined for xml output.

If parent contains some amount and its children also contain some amount, then the balance report can be shown as:

1200    parent (200)
  500        child1
  500        child2

https://github.com/puffnfresh/wartremover

When an account name is right-clicked, show a menu:

• Summary
• Transactions

Transactions is already implemented.

Summary will show two charts:

1. Balance v/s Time graph (line or bar chart)
2. Related accounts (stack chart)

Depends on #16

Support for tagging transactions.

As in ledger, three types of tags could be envisioned:

• Simple tags (just a label)
• Tags with values (key value pair, with string values)
• Tags with typed-values (key value pair, with a precisely defined value type

This issue is about simple tags.

Functions that get information about accounts.

Eg account('xyz').total

Math functions

min, max, pow, etc

Date functions

(perhaps, can't think of use-cases)

Something like:

{
def x = 10

def defautlAccount = "Cash"

2013/1/1
  Expense           -100

}

# x not visible here
# defaultAccount not applicable here

• Scopes can be nested
• Every .ledger file will have an implicit scope surrounding the entire file contents.

Travis CI looks good and supports Scala out of the box.

Comment by @jaa127 via email:

It would be cool to be able generate transactions like these:

2015-01-02   tmx 18/45 D12L
        {
                Gas:He:Tank:102         -(273 - 243) ;  40 bars
                Gas:He:Tank:103         -(100 - 70) ; 30 bars
                Gas:He:Tank:104         -(80  - 50) ; 30 bars
                Divers:jaa127:He ; <== No amount here!
        }
        {
                Gas:O2:Tank:208         -(180 - 171) ; 9 bars
                Gas:O2:Tank:209         -(143 - 134) ; 9 bars
                Divers:jaa127:O2  ; <== No amount here!
        }

Because in real life it is "single transaction", but with current
mechanism, it has to be either:

• all postings has to be calculated (and then there is change to
  miss-calculate gas amounts by type, and mix up gas types. E.g. on
  Abandon "bars" will zero out, but credit/debit by gas type is wrong. If
  that happens, then it will badly mess up billing because Helium is 5-10x
  more expensive than Oxygen in Finland.
• Or there has to be two separate transactions, which isn't so nice. For
  diver who is mixing gases it would be really nice to have one clean and
  clear single transaction, which is listing all gases what you used.

So scopes looks like perfect solution for that!

PS. This was clubbed with the scopes idea, but I think it is better to give it a separate name, say, "transaction sub-group".

Have you thought about putting the project on maven, so that one could simply reference it in sbt dependencies?

Sometimes, due to typos or WIP entries, there are accounts that are neither in Balance sheet nor in P & L statements.

These need to be highlighted.

Two ideas:

1. Highlight them in the All report. Could be achieved by adding a configuration in the report.
2. Add a top-level configuration to recognize standard Account names. A summary of all non-standard account names can then be presented as a warning message.

Following the discussion from PR #70, I think abandon should be more consistent in how configurations are named. I have been loosely following this idea:

There are two ways to get data out of abandon: report and export.

• report will show processed data from abandon with some visual formatting.
• export will emit raw data in some standard format (currently xml and ledger)

However, that is probably not a good way to define report and export. Sometimes you need processed data in a standard format, or raw data shown with some visual formatting.

Hence, it would be better to separate the "processed" / "raw" distinction from the "report" / "export" distinction. Here's the new plan:

• report is for any visually formatted output, intended for direct human consumption.
• export is for non-visual output, intended to be machine readable.

Reports are in textual format, for now. In addition, the GUI can show the reports in an interactive format.

The current export configurations would need to be expressed differently:

With this change, two new types of exports that will also be supported:
exports += {type = balance, format = xml}
and
exports += {type = transactions, format = ledger}

To summarize: the distinction between report and export will be clearer; report is for human consumption while export is for machine-readable output. Both reports and exports will have two parameters: a type and a format. The format for report is currently implied to be text, while for export it will be specified in the configuration.

Currently transactions are flattened and then exported. The advantages of the current approach are:

• Easy for the consumer to easily slurp the data
• Filtering by account name is possible before export.

Disadvantages of the current approach:

• Analysing the data is not possible (since grouping information is lost).
• Data might be leaked through related transactions

It would be better to emit groups of transactions. This would not allow filtering while exporting but that might be good in a way since data doesn't get leaked unintentionally.

The date range can be used by reporting tools for determining opening balances.

Just like unary - operator, we can support unary + operator.

It is convenient to have when quickly toggling the signs of an expression.

The unit tests are already present, but currently marked as pending.

Assigning to @sheetalk

It should be possible to fold the children of an account, and this setting should be per report.

For example, if Expense is configured to be folded, then its children such as Expense:Food and Expense:Entertainment would be folded into Expense. So for that report, the children of Expense would be effectively non-existent.

Use cases

• Closing of accounts in a more human readable format (see below).
• reduce clutter in a report.
• prevent details from leaking when they are not needed by the recipient of a report.

Closure of accounts and folding

When exporting in ledger format, it will be possible to close certain accounts ( #11 ). Folding can be especially useful here. It is easier to read this:

2013/3/31
  ; Closure
  Capital:Profit     3,000
  Income            -4,000
  Expense           +1,000 

than

2013/3/31
  ; Closure
  Capital:Profit     3,000
  Income:Sales      -3,000
  Income:Service    -1,000
  Expense:Personal    +500 
  Expense:Work        +500