Re: Exchange Rates

Hi Michael,

On Sun, Jul 12, 2015 at 5:21 PM, Michael Richardson <..hidden..> wrote:

Erik Huelsmann <..hidden..> wrote:
> It's horribly broken. I too use that workaround, but better yet, I'm working
> on resolving the issue completely: that is, to make sure the exchange rates
> get stored per transaction. Or rather, we'll start storing a local and a
> foreign currency amount. Anybody who wants to know the rate can probably do
> the math themselves.

Huzzah!!! My CC bill tells me the two numbers, and I have no idea what
rounding rules they apply, and the wire transfer people do some other
thing...

Yea. I'm running into the issue myself that the CC company, the bank and PayPal each have their own idea about today's rate.

One of the things I'd like to have on the reconcilliation page is the ability
to enter per-transaction fees (including monthly fees and interest). So that
if I invoice $1000, and I'm paid by wire-transfer, I usually get $992.50.
So I wind up entering a bank transaction fee of $7.50, which is fine, but I
wish I could do it in one place, and associate the two things. It also gets
messier if there is an FX involved as well, and sometimes the 7.50 is in the
FX...

This is a long-standing issue for me too. I'm affraid I can't fit it in the current project: the current project is a branch of 1.4, which is pretty hard to develop a good UI for. However, as I noticed, you are aware of the fact that there are a lot of things changing with 1.5 (to which I'll be porting this project, of course!). One of the things that's changing is that it's much easier to build a rich browser-based client-side UI, which means that it's much easier to add this functionality to 1.5+. I'm a fan of small steps, so, I'd rather release 1.5 sooner than later (as soon as it matures enough to be released, of course) -- which makes for some good discussion on when to merge big changes like the multi-currency change. (If it's not landing in the general 1.5 release, I'm going to maintain a branch of it with the multi-currency code -- that makes it both easier to merge into 1.6 *and* I'll want to use it myself :-) )

[ snip ]

> Same here. If the fundraiser gets enough funds (and I finish the job), we'll
> do the math in the screen so you can see the outcome and be the judge of what
> the correct rate is or simply enter both numbers.

Woohoo!!!!
I also have some _javascript_ totals that I'd like to add.
My struggle in getting up to 1.4.12 was in part so that I could run closer to
bleeding edge, so that when I patch something for myself, it will be easier
to push upstream.

Ok. Perfect! Actually, just providing the patches as-is, might be enough. It's a whole lot better than not providing them at all!

I also would love to have a G+ screen share to learn how you guys are doing
testing...

I'm affraid you won't find much that you didn't figure out yourself, if you're talking the PostgreSQL or Perl sides. On the JS side, I heavily work with the Firefox and Chrome debuggers with breakpoints in the asynchronous events. At this point, a lot is manual, I'm affraid (not the database side, but the UI side is). However, since changes like the ones that have recently landed on master ('frameless', 'PGObject') and the ones that are *going* to need to land on master in the near future ('multi currency', 'financial rewrite'), I'm desperately looking for testing frameworks. I think that automated testing is the only way forward, even if only to establish minimal correct operation. I've seen changes break loading of seemingly independent pages just once too often.

I'm now looking at this framework which seems to integrate with Travis-CI and OpenSauce to do our continuous integration testing for both the database side *and* the UI side (our database side and Perl regression tests already run on Travis-CI): http://theintern.github.io/

So, if you want to lend a hand coding on our project, please just say so and we'll help you get your development skills sharpened for LedgerSMB!

Regards,

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.