+beancount On Sat, Oct 1, 2016 at 3:24 PM, Martin Blais <[email protected]> wrote:
> On Fri, Sep 30, 2016 at 11:56 AM, Ratish Punnoose <[email protected]> > wrote: > >> Hi Martin, >> I am doing the accounting for a school festival and was scoping out >> your project, beancount. It looks very cool. Thanks for developing it. >> > > Thanks! > > > In your comparison document (with ledger + others), you mention that >> beancount only has a resolution of a single day. Do you have any future >> plans to provide time resolution? >> > > No. > > A while back I decided it was out of scope and this would keep the code > simpler. So far it seems like it was a good decision. If you need something > like that - e.g. for intra-day trading with 100+ trades, or for managing a > large sales operation - I figure more specialized software is in order > anyhow. > > > In my use case, a festival spans multiple days but it is extremely useful >> for us to get reports hour-by-hour for many booths. We currently do this >> with spreadsheets. This is needed for us to make a lot of decisions, >> checking trends, comparing historical performance, and correlating with >> other events that are happening. I can also imagine other use cases, >> where accounting reports are done per multi-hour shifts. >> It would be quite useful for beancount to provide at least a one-hour >> resolution. >> > >> If you don't have plans to support this, could you provide some advice on >> what modifications would have to be made to support this. For a start, we >> wouldn't need to report across timezones. Does that make it simpler? If >> it is not a huge endeavor, I would like to see if I can contribute on this >> front. >> > > Hmm, let's see. I think you could actually do this with the current system > with pretty minimal changes. > > First, let me explain how sorting works, which is the key subject here > when we think about time. One important invariant Beancount ensures is that > the order of your input is not relevant. All directives - of all types, > Transaction and others, like Balance - are sorted in data order, and then > by type. If on the same date, Open directives always come first, then > Balance directives (thus they apply at the beginning of a day), then the > Transactions and everything else, and finally, Close directives. The code > that expresses this rule is here: > https://bitbucket.org/blais/beancount/src/5d1390225e9a27590ddace440ebb34 > b723f731c8/src/python/beancount/core/data.py?at= > default&fileviewer=file-view-default#data.py-482 > > Note also that the line number is included in the sort-key, but none of > the calculations anywhere do anything special within a day, so it doesn't > matter. It's only there to ensure a "stable" sorting order (meaning every > time you sort you obtain the exact same result), which helps when writing > tests. > > Adding storage is trivial; ideally one would include that in the grammar, > but that would be a pretty invasive change. I think you could start by > adding some metadata field, e.g. "time", and pulling it in the sort-key, it > it's present, e.g. > > 2016-10-01 * "Sale #1" > time: "04:05" > ... > > > and monkey-patching data.entry_sortkey() like this: > > def entry_sortkey(entry): > return (entry.date, SORT_ORDER.get(type(entry), entry.meta.get('time', > None), entry.meta['lineno']) > > Note a few things: > > - I'm placing the sort order in front of the time here; I'm assuming you > don't need Balance check within the day. If you do, you could make those > respect time and change the field order. I'm not sure if everything else > keeps working - you'd have to try it out - but I suspect it will. > > - I'm using .get() instead of [] on "meta" so that you may leave the field > as absent. This means that for transactions with no time, they'll appear > before the other entries with time. You could provide a default value for > time of your own choice if you'd want to do differently. > > - The meta-data value in my example is a string. You might want to > implement a plugin that verifies that the input syntax is correct if those > are manually entered, e.g. "\d\d:\d\d". > > Based on this, you could then use the SQL shell to extract the time and do > run some aggregations. I think you'd want to add a few custom functions to > the bean-query environment, in here: > https://bitbucket.org/blais/beancount/src/5d1390225e9a27590ddace440ebb34 > b723f731c8/src/python/beancount/query/query_env.py? > at=default&fileviewer=file-view-default > > I'm thinking of some functions to get the time metadata (META() can do > that, but you might want to add a virtual "time" column which would look > nicer), and some functions to round your time strings to e.g. hours. > > > So essentially, I just fleshed out how to add time to Beancount. If > - doing this doesn't add significant processing time, > - adding this time metadata is optional > - we wrote a lot of unit tests, > I'd consider adding this to the default branch. > > As always, the problem with these things is all the unintended > consequences down the road, and the devil is always in the details. > > I hope this helps, please do let us know if you give this a shot. > > > > > >> >> Thanks >> Ratish Punnoose >> >> >> >> >> > -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhPN%3DsT2Cnu5ji5Lfwut2ZqfQbj1i5UEdanhU2v_mXNmiw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
