> > Bradley M Kuhn writes:
> > Currently, there are various types of transaction I'm doing with Ledger-CLI
> > that are unpredictable with regard to rounding (of course, johnw can always
> > explain it to me -- but he's not always going to be available to talk to
> > everyone's auditors ;).
J
Hi Jostein,
thanks for your interest and message, it motivated me to actually do the work :)
Here's a pull request with the changes you can test:
https://github.com/ledger/ledger/pull/284
Let me know if you have any issues with it, or any suggestions.
I just recently found out about the XML, so
Building latest git, I get:
-- Up-to-date: /usr/local/include/ledger/system.hh
-- Up-to-date: /usr/local/bin/ledger
-- Up-to-date: /usr/local/share/man/man1/ledger.1
CMake Error at doc/cmake_install.cmake:40 (FILE):
file INSTALL cannot find "/home/b0ef/.pkg/ledger//doc/ledger3.info".
Call Stack
what versions of sed and texinfo are in your path? If they are too
old info won't build.
On Thu, May 8, 2014 at 6:17 AM, Esben Stien wrote:
> Building latest git, I get:
>
> -- Up-to-date: /usr/local/include/ledger/system.hh
> -- Up-to-date: /usr/local/bin/ledger
> -- Up-to-date: /usr/local/shar
Craig Earls writes:
> what versions of sed and texinfo are in your path? If they are too
> old info won't build.
I don't even have texinfo, but I would assume it shouldn't fail such as
it does on install.
It doesn't affect ledger install.
--
Esben Stien is b0ef@e s a
When I get an incoming invoice from a company called foo, I do:
2014-04-21 REG foo.33341
;[[id:0b073899-81b7-4e41-b137-f62c839d316f][foo.33341]]
Expenses:4110 381
Liabilities:2400:foo
2014-04-21 PAY foo.33341
;[[id:0b073899-81b7-4e41-b137-f62c839
On Thursday, 8 May 2014 06:03:40 UTC+5:30, John Wiegley wrote:
>
> > tripun goel > writes:
>
> > The point to note is that Ledger-CLI uses multiple precision floating
> point
> > numbers via MPFR library.
>
> Hi Tripun, welcome to Ledger development. :)
>
Thanks
>
> Ledger-CLI does no
Hi Johann, John,
That works here. Thanks.
I updated the acprep script to load the dependencies for Ubuntu trusty,
that worked as well.
Attached updated acprep diff to this posting.
BR,
Hans Erik
On Wednesday, May 7, 2014 7:10:52 PM UTC+2, Johann Klähn wrote:
>
> John, All,
>
> I think I may h
I found this option working.
D AMOUNT Specifies the default commodity to use, by specifying an amount in
the expected format. The xact command will use this commodity as the
default when none other can be determined. This command may be used
multiple times, to set the default flags for differe
> Martin Blais writes:
> Just out of curiosity: why don't you just use decimal representation?
> Wouldn't that be enough? In which case does it help?
Rationals take move all of the decision making out of Ledger's core, and into
display. There's really nothing dead simpler than having a plai
> tripun goel writes:
> Did you notice that Income of $0.0169 which was from the first transaction
> is missing in the final result. Not to mention that the precision of lot
> prices is ignored for which bug 992 is filed.
Nice find, Tripun, thanks for filing that bug report.
> Will it not b
> tripun goel writes:
> What do you think , should it remain as an input format or it will do better
> as an option to command line ? I mean you cannot expect people to use it in
> input file if it is imported from other programs such as a csv or gnucash
> file?
We should certainly support b
> Esben Stien writes:
> 2014-04-21 PAY foo.33341
> ;[[id:0b073899-81b7-4e41-b137-f62c839d316f][foo.33341]]
> Liabilities:2400:foo381
> Assets:1920
> I've marked each transaction with a link to the corresponding document that
> describes the invoice, b
I requested a few years back, did some work on it, but ultimately
decided it wasn't worth the effort. But I would still love to have
better precision control on display.
I wanted a formatting command that would let me display the operand at
any precision I desired rather than a high level option.
14 matches
Mail list logo