Hi Chris,
> I am thinking we should do RC1/code freeze on Monday and aim for a full
>>> release on Wednesday if no further problems are found.
>>>
>>> Any objection to this?
>>>
>>
>> As we discussed through gTalk, I'll be doing testing of the new foreign
>> currency code as well as the changes to the bulk payments.
>>
>> In addition to that, when you release .11RC1, my colleague wants to test
>> it herself as well. So, I'll upgrade a copy of our production system to
>> .11RC1 and test it on Tuesday and Wednesday. She'll send us her findings
>> before Wednesday 14.00 (Pacific time).
>>
>
> Perfect.
>
Today I executed these steps:
* Updated the branches/1.3 working copy I use for testing to the tip of the
branch
* Dumped the production database using pg_dump
* dbdrop-ped the existing testing database
* dbcreate-d a new one
* loaded it with a copy of the production database using 'psql -f backup'
* ran the setup.pl-based upgrade process on it
>From here, I was in a position to test.
So, what I did was create a bulk payment with many-many invoices in them.
But from there on I focussed on a single invoice each time. What I did was
select Voucher-Payment menu, create a batch, pay all items in it and post
the batch.
>From there I first checked the batch lines and picked a single vendor
invoice to analyse. The invoice I chose was INV2-11 from VENDOR (as you
guessed: anonymized, but that shouldn't matter). The invoice is posted in
GBPs in a company administered in CAD. The resulting lines are these:
Date Reference Description Source Debit Credit Account 14-11-2011 INV2-11
VENDOR <goog_1080361765> 24.30 <goog_1080361765> 5010 General expenses
14-11-2011 INV2-11 VENDOR <goog_1080361765> 14.99 <goog_1080361765> 5010
General expenses 14-11-2011 INV2-11 VENDOR <goog_1080361765>
<goog_1080361765>
39.29 2100 Accounts Payable 11-2-2012 INV2-11 VENDOR 1500 <goog_1080361765>
33.40 1060 Chequing Account 11-2-2012 INV2-11 VENDOR 1500 63.52
<goog_1080361765> 2100
Accounts Payable 11-2-2012 INV2-11 VENDOR 1500 <goog_1080361765> 30.13 4450
Foreign Exchange Gain / Loss 102.81 102.81
The lines from 14-11-2011 are the creation lines and the lines of today are
the payment lines.
>From looking at the lines, it looks like the signs of the payment lines are
correct. However, what's further going on isn't clear to me. I was
expecting the AP line in the payment to be the same as the one in the
creation: 39.29 CAD. As a consequence, I can't make heads nor tails from
the posting to the fx gain/loss account (this p&l doesn't have separate
accounts for gains / losses). Assuming the checking account posting is
correct, I'd expect an fx posting of 5.89 and an accounts payable posting
of 39.29. OTOH, it's all well balanced ;-)
Going to test the payment reversals, I went in and selected the payment
that we'll want to reverse in production as well. You'll find it in the
table below. The lines with the numbers in 'normal color' concern the
creation of the open item. The lines with the dark green colored numbers
concern the payment. The use case here is that they were entered on 23-12,
but the real payment had happened way before. So, we want to reverse the
payment and enter it correctly. The reversal as generated by the current
reversal code are the lines with the numbers marked in light green.
Date Reference Description Source Debit Credit Account 15-4-2011 INV4-11
VENDOR 189.30 5011 Expenses. 15-4-2011 INV4-11 VENDOR 105.12 5011
Expenses. 15-4-2011 INV4-11 VENDOR 294.42 2100 Accounts Payable
23-12-2011 INV4-11 VENDOR other 833.60 299.30 1071 PayPal Merchant Account
23-12-2011 INV4-11 VENDOR other 833.60 294.42 2100 Accounts Payable
23-12-2011 INV4-11 VENDOR other 833.60 4.88 4450 Foreign Exchange Gain /
Loss 1-1-2012 INV4-11 VENDOR other 833.60 160.91 1071 PayPal Merchant
Account 1-1-2012 INV4-11 VENDOR other 833.60 294.42 2100 Accounts Payable
1-1-2012 INV4-11 VENDOR other 833.60 133.51 4450 Foreign Exchange Gain /
Loss 888.14 888.14
As you can see, the reversal on the Accounts Payable account is correct,
but the merchant account isn't what I'd expect. Since I'm simulating last
year was already closed when reverting the payment, I can't enter a posting
date before 1-1-2012.
The huge FX difference comes from the fictitious rate that I used to post
the 1-1 posting. It could be half the rate or less of what was used to post
the actual posting.
What I want from the reversal is for it to create a posting which exactly
offsets the posting, making it like the posting never happened
(cumulatively) - both on the balance as in the P&L. I'm not sure this can
be achieved in our current data model though: we have no way of recording
the fact that the 2012-1-1 payment should have used the fx rates of
23-12-2011...
Going back and testing that the reversal exactly reverses all posting
effects as long as I'm able to post in the given period gives me a positive
test result.
As a last and unrelated test result, I seem to have file link issues "all
of a sudden" (that is, I've never used the feature and its authorizations
seem to start affecting me):
42501:ERROR: permission denied for relation file_links
CONTEXT: SQL function "file__list_links" statement 1
If this is from a recent change, it would probably be good to fix it before
we release .11 I've been messing with my system recently though - removing
roles from tests having gone haywire. So, it could be those cleanups have
affected my system more than I want to.
Hope these tests are in-depth enough for you to have a look at fixing
things. If you want me to, I can definitely agree that fixing the data
model isn't for the faint of heart in a patch release. Maybe we should move
the data model fix part of the payment reversals to the 1.4 release. If we
want to release that fix soon but as part of 1.4, we probably want to scale
down on the size of 1.4. For me, the fix isn't the most important one,
since the posting I want to correct is still in an open period. So I can
just post the reversal on the exact same date as the payment.
Bye,
Erik.
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
