thank you for giving this some consideration. I deliberated using explicit
costs in the transaction but I don't particularly like this approach. It
would mean that we would need to regenerate these files every time there is
a change to the rates structure.
Ideally I would like the following to work as it would be the most flexible:
; VALUE:: (post.date < [2017-09-01] ? £350 : £450) / 1d
I could use a similar approach to match postings on tags or other metadata.
Unfortunately this rounds to two decimals for some reason as demonstrated
in the gist that I linked to in my original email.
On Tue, Feb 6, 2018 at 1:55 AM, <johanne...@gmail.com> wrote:
> just an idea, an alternative solution would be to make the import script
> aware of the different rates of each developer, so that each time statement
> is imported with its corresponding price. For example, if Alice earns 20
> dollars per hour:
> 2017-08-15 Work by Alice on the project in August
> Work:Client:Project:Alice 4h @ =$20.00
> This would provide a maximum of flexibility since you'd be free to model
> different rates for different team members, time spans, customers, projects
> best regards, Johannes
> You received this message because you are subscribed to a topic in the
> Google Groups "Ledger" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> To unsubscribe from this group and all its topics, send an email to
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.