Hi,
On the whole, this all seems like a good strategy, and for what I
understand of the system, I'm entirely on board. Couple comments:
On 01/23/2014 02:37 PM, Erik Huelsmann wrote:
Hi Chris,
On Thu, Jan 23, 2014 at 3:48 AM, Chris Travers
<[email protected] <mailto:[email protected]>> wrote:
Hi all;
1. We need to be able to handle arbitrary two-currency or even
three currency transactions. For example, if one has one's books
in USD and transferring money from a GBP to an EUR account, this
must be supported.
Right. What's more, I'd like the design (although possibly not the
immediate implementation) to allow for assets to be held in non-base
currencies. E.g. to hold a USD current account in a company which is
EUR based. Part of this requirement is the need to be able to revalue
the asset -- report it as having a different current value than the
value that it had when the posting was originally created.
2. We need to be able to handle per-transaction exchangerates.
Right. I'd say that we need a per-date default exchange-rate as well
-- one that's picked up if no other exchange rate is specified.
To me, this requirement solves the following use-cases:
- different banks (or bank and credit card) with different exchange
rates for the same currencies on the same date
- FX transaction reversal of a transaction in a closed period with a
currency different from the current default
One new consideration: Bitcoin. I just attended a talk yesterday that
really made me see the value of digital currencies in terms of fraud
prevention -- compared to credit cards, it's a much, much better deal
and far less risky for merchants. But its value, obviously, fluctuates
dramatically at any time.
At least being able to store and report on accounts stored in BTC would
be an easy way to become an early accounting system with support for
it... then we could add a digital wallet support later as an add-on or
something... See some of my thoughts here:
http://www.freelock.com/blog/john-locke/2014-01/bitcoin-future-e-commerce
* A functional interface (before a webservice interface), so we get
per posting/transaction integrity checks in place
Not sure I agree with this one. If we make the web service interface
essentially extend an ORM to http, we can use http requests for testing.
It's pretty easy to put together a generic test harness that would allow
us to test requests and responses, aside from any UI issues. By
"functional" do you mean functions in the database, or functional forms
for user input? If the first, ok. If the last, I would like to see the
REST interface use exactly the same code as the form handlers -- the
form handlers just providing an HTML client layer that shares the same
business logic.
Cheers,
John Locke
http://www.freelock.com
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
