Hi all;
I would like to submit my plans for financial rewrite and suggest we
discuss any expectations. Existing areas of testing and what we can do to
ensure they are still met will be added below.
The financial rewrite will be done in such a way as to allow 1.5 to be
released even if it is not complete. However, we need to try hard to avoid
making it a moving target, so hopefully this will provide some guidance
there as well.
I have basically scoped out the work required, and come up with the
following requirements:
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.
2. We need to be able to handle per-transaction exchangerates.
3. For reporting and referential integrity purposes, we need a more
unified database structure. Some reports have test cases, notably the PNL
reports.
4. For COGS tracking, we need to be able to audit how this is done, so as
bugs are reported, we can track full changes of state across time. I have
COGS tests btw.
5. We need to get rid of the silly restriction that ensures you can't have
accounts in different places of the ar/ap transaction screen.
So my plan is basically as follows:
1. Rewrite currency handling, and provide an opportunity to set
per-currency allowed exchangerate variances. This option would be
initially hidden by css. Initially I will just propagate the changes to
the defaults table to avoid messing with the old code. This will be done
in trunk and affect the full release both new and old code.
2. Write a journal entry module. Basic test cases would be written
including on the db-side posting and reversing a balanced transaction, and
on the Perl side, attempting to post an unbalanced transaction (and having
it fail). I am not quite sure how to handle this in terms of save points,
but this can be figured out. Extending our current test framework to add
this will not be problematic. After this point, I would really like new
reports to include logic against this db model instead of the old acc_trans
tables.
3. Port the invoice module I wrote using PGObject::Simple::Role from wxpos
to Moose and move this area over. We'd remove payment handling since that
would be separate. I don't expect this to be too hard.
4. We'd write a new payment object model following this. Once this is
done, wxpos can take over some part of the role of a data insert tool for
reports development etc. I expect that the end result will be some of our
current sql will be portable, and a lot of stuff will be rewritten. This
may be one of the harder aspects.
5. The reconciliation module would need to be ported. This is not likely
to be too hard. Existing reconciliation tests would be expected to pass.
6. The financial reports would be gone through and ported over.
7. At that point we'll branch, switch-over, make sure tests work, and pull
the version with the removed code back into 1.5.
With the advancements that have taken place in 1.4, I expect 1-3 to happen
fairly quickly. The real unknowns are 4 and 6.
Any feedback?
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more.shtml
------------------------------------------------------------------------------
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
